Wicket Session grows too big real fast

2008-11-26 Thread jhp

Hi,

I have a serious problem with our application. It uses
wicket+guice+hibernate technologies. The problem basically is that the
application was developed with very little attention to the possible session
size, and it is biting us now.

The are several domain classes and the dependecies are not the simplest
possible. For example frontpage shows a listing of objects, and for each
object it shows a name and a link etc.
For the listing I have used LoadableDetachableModel, the model is passed to
a Panel, that then uses this type of structure:
ListView recommendationListView = new ListView(recommendationListView,
recommendationListModel) {
@Override
protected void populateItem(ListItem item) {
final Recommendation recommendation = (Recommendation)
item.getModelObject();
ExternalLink link = new
ExternalLink(recommendationLink,/recommendation/id/ +
recommendation.getId());
item.add(link);

And this type of structure is used all over the application. I thought that
this was OK, but now I am not sure. When I run the code in production
environment and test it with jmeter script, i can see that the the memory
tomcat reserves grows rapidly. When I shutdown tomcat and investigate the
SESSIONS.ser file that tomcat generates, I can see there are lots of domain
classes serialized to the session. And as domain classes have other domain
classes as collections and they might have still more (altough I use
FetchType= Lazy whereever I can), it's easy to see why sessions start to
take too much memory and eventually java.lang.OutOfMemoryError: Java heap
space appears.

Are there any possible things that I could try? Or do I have to go throug
the code and try to change everything to LoadableDetachableModel, which will
be very tedious. Any help to the problem, or more accurate ways to pinpoint
the problem, would be greatly appreceated.

BR,
Jukka



-- 
View this message in context: 
http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697077.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: Wicket Session grows too big real fast

2008-11-26 Thread Martijn Dashorst
With Wicket 1.3 only one page should be stored in session. You should
check if you don't keep references between pages - that would result
in 1+N pages (with N being the number of pages you reference in your
page).

Other than that: using LDM's and DataView/DataProvider instead of
ListView will help considerably.

Martijn

On Wed, Nov 26, 2008 at 10:02 AM, jhp [EMAIL PROTECTED] wrote:

 Hi,

 I have a serious problem with our application. It uses
 wicket+guice+hibernate technologies. The problem basically is that the
 application was developed with very little attention to the possible session
 size, and it is biting us now.

 The are several domain classes and the dependecies are not the simplest
 possible. For example frontpage shows a listing of objects, and for each
 object it shows a name and a link etc.
 For the listing I have used LoadableDetachableModel, the model is passed to
 a Panel, that then uses this type of structure:
 ListView recommendationListView = new ListView(recommendationListView,
 recommendationListModel) {
@Override
protected void populateItem(ListItem item) {
final Recommendation recommendation = (Recommendation)
 item.getModelObject();
ExternalLink link = new
 ExternalLink(recommendationLink,/recommendation/id/ +
 recommendation.getId());
item.add(link);

 And this type of structure is used all over the application. I thought that
 this was OK, but now I am not sure. When I run the code in production
 environment and test it with jmeter script, i can see that the the memory
 tomcat reserves grows rapidly. When I shutdown tomcat and investigate the
 SESSIONS.ser file that tomcat generates, I can see there are lots of domain
 classes serialized to the session. And as domain classes have other domain
 classes as collections and they might have still more (altough I use
 FetchType= Lazy whereever I can), it's easy to see why sessions start to
 take too much memory and eventually java.lang.OutOfMemoryError: Java heap
 space appears.

 Are there any possible things that I could try? Or do I have to go throug
 the code and try to change everything to LoadableDetachableModel, which will
 be very tedious. Any help to the problem, or more accurate ways to pinpoint
 the problem, would be greatly appreceated.

 BR,
 Jukka



 --
 View this message in context: 
 http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697077.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]





-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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



Re: Wicket Session grows too big real fast

2008-11-26 Thread Johan Compagner
if you make this:

 final Recommendation recommendation = (Recommendation)
item.getModelObject();

not final does it compile?

If it doesnt then you have a leak

johan


On Wed, Nov 26, 2008 at 10:02 AM, jhp [EMAIL PROTECTED] wrote:


 Hi,

 I have a serious problem with our application. It uses
 wicket+guice+hibernate technologies. The problem basically is that the
 application was developed with very little attention to the possible
 session
 size, and it is biting us now.

 The are several domain classes and the dependecies are not the simplest
 possible. For example frontpage shows a listing of objects, and for each
 object it shows a name and a link etc.
 For the listing I have used LoadableDetachableModel, the model is passed to
 a Panel, that then uses this type of structure:
 ListView recommendationListView = new ListView(recommendationListView,
 recommendationListModel) {
@Override
protected void populateItem(ListItem item) {
final Recommendation recommendation = (Recommendation)
 item.getModelObject();
ExternalLink link = new
 ExternalLink(recommendationLink,/recommendation/id/ +
 recommendation.getId());
item.add(link);

 And this type of structure is used all over the application. I thought that
 this was OK, but now I am not sure. When I run the code in production
 environment and test it with jmeter script, i can see that the the memory
 tomcat reserves grows rapidly. When I shutdown tomcat and investigate the
 SESSIONS.ser file that tomcat generates, I can see there are lots of domain
 classes serialized to the session. And as domain classes have other domain
 classes as collections and they might have still more (altough I use
 FetchType= Lazy whereever I can), it's easy to see why sessions start to
 take too much memory and eventually java.lang.OutOfMemoryError: Java heap
 space appears.

 Are there any possible things that I could try? Or do I have to go throug
 the code and try to change everything to LoadableDetachableModel, which
 will
 be very tedious. Any help to the problem, or more accurate ways to pinpoint
 the problem, would be greatly appreceated.

 BR,
 Jukka



 --
 View this message in context:
 http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697077.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: Wicket Session grows too big real fast

2008-11-26 Thread jhp

Well, yes references to pages seems to be given as constructor arguments to
several pages. The idea is that if 'Cancel' is clicked, application goes
back to previous page. The possibility to go back more than one page is not
necessary. Is the correct way to implement cancle with some javascript that
does something like user clicking previous page?

Jukka


Martijn Dashorst wrote:
 
 With Wicket 1.3 only one page should be stored in session. You should
 check if you don't keep references between pages - that would result
 in 1+N pages (with N being the number of pages you reference in your
 page).
 
 Other than that: using LDM's and DataView/DataProvider instead of
 ListView will help considerably.
 
 Martijn
 
 

-- 
View this message in context: 
http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697523.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: Wicket Session grows too big real fast

2008-11-26 Thread jhp

In that place, it compiles without it, but I have another class that has
something like this:
final Recommendation currentRecommendation = (Recommendation)
recommendationModel.getObject();
.
.
.
add(new Label(usersChoice, getUsersChoiceString(name.getFirstname())) {
@Override
public boolean isVisible() {
  return currentRecommendation.getSupplier() != null;
}
});

And it doesn't compile without final. so does that mena that this is teh
palce which forces the recommendation object to be stored in the session? I
have to admit that it didn't occur to me.

Jukka


Johan Compagner wrote:
 
 if you make this:
 
  final Recommendation recommendation = (Recommendation)
 item.getModelObject();
 
 not final does it compile?
 
 If it doesnt then you have a leak
 
 johan
 

-- 
View this message in context: 
http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697681.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: Wicket Session grows too big real fast

2008-11-26 Thread jhp

In that place, it compiles without it, but I have another class that has
something like this:
final Recommendation currentRecommendation = (Recommendation)
recommendationModel.getObject();
.
.
.
add(new Label(usersChoice, getUsersChoiceString(name.getFirstname())) {
@Override
public boolean isVisible() {
  return currentRecommendation.getSupplier() != null;
}
});

And it doesn't compile without final. so does that mean that this is the
place which forces the recommendation object to be stored in the session? If
so, I have to admit that I missed it entirely.

Jukka


Johan Compagner wrote:
 
 if you make this:
 
  final Recommendation recommendation = (Recommendation)
 item.getModelObject();
 
 not final does it compile?
 
 If it doesnt then you have a leak
 
 johan
 

-- 
View this message in context: 
http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697806.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: Using CompoundPropertyModel with FormComponentPanel

2008-11-26 Thread Ned Collyer

I'm not sure how to get the textfield editor working on the property name
of the user object - I am aware the CPM is trying to look at the id editor
which is wrong :).
-- 
View this message in context: 
http://www.nabble.com/Using-CompoundPropertyModel-with-FormComponentPanel-tp20697019p20698456.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]



triggering post of a for from client side

2008-11-26 Thread dshapi

hi,
I need to trigger the post of a form - from the client side with java script
, but all the solutions that i have found don't work with wicket.
i have tried  document.forms['commentForm'].submit();  in script -
doesn't work.
(when commentForm is the name of the form that is generated in the mark up
of the wicket ).

i all sow tried to trigger the  submit button that is in the form but
.click() doesn't work, 
i have managed only to  trigger Links with window.location = link.href;

any ideas ?
 

-- 
View this message in context: 
http://www.nabble.com/triggering-post-of-a-for-from-client-side-tp20699113p20699113.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: Using CompoundPropertyModel with FormComponentPanel

2008-11-26 Thread Nino Saturnino Martinez Vazquez Wael

Hi Ned

you can call bind on the compound property model..

labelText = new Label(labelText, CPM.bind(propertyname));

You can also do this for your property models btw...

Ned Collyer wrote:

I'm trying to throw together some components for easily creating accessible
forms.

I'm a fair bit along - just need some assistance with how to structure the
class for use with CompoundPropertyModels.

I want to be able to do the following:

Form form = new Form(form, new CompoundPropertyModel(new User());
form.add(new LabelledTextField(name))

But I'm having difficulty setting the property model against the textfield
inside my LabelledTextField.

I can retrieve the values just fine, and they are set on the object from the
forms CPM.

I am using a fragment so that markup can be edited in a single place for all
labelled form fields.  And different markup providers or variants can be
used if any edge cases occur for any projects.

The form fields can also used as easily as any other form fields in wicket -
this is a different approach from wicketopia - which I've had a good dig
through.

I've gotta be close!


/* the class itself */

private final FormComponentLabel label;
private final Label labelText;
private final TextFieldT editor;
private Fragment componentFragment;

public class LabelledTextFieldT extends FormComponentPanelT {

public LabelledTextField(String id) {
super(id);

componentFragment = new Fragment(COMPONENT_ID, textField, this);
editor = new TextFieldT(editor, new PropertyModel(this,
String.format(model.%s, id)));
label = new FormComponentLabel(label, editor);
labelText = new Label(labelText, TBA);
label.add(labelText);

componentFragment.add(editor);
componentFragment.add(label);

add(componentFragment);

setRenderBodyOnly(true);
}

protected void convertInput() {
setConvertedInput(editor.getConvertedInput());
}

public String getInput() {
return editor.getInput();
}
}
  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


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



Re: triggering post of a form, from client side

2008-11-26 Thread James Carman
You may want to look at AjaxFormSubmitBehavior.  If you can't use that
directly, the code might give you an idea of how to write your Javascript to
do form submissions manually.

On Wed, Nov 26, 2008 at 6:27 AM, dshapi [EMAIL PROTECTED]wrote:


 hi,
 I need to trigger the post of a form - from the client side with java
 script
 , but all the solutions that i have found don't work with wicket.
 i have tried  document.forms['commentForm'].submit();  in script -
 doesn't work.
 (when commentForm is the name of the form that is generated in the mark up
 of the wicket ).

 i all sow tried to trigger the  submit button that is in the form but
 .click() doesn't work,
 i have managed only to  trigger Links with window.location = link.href;

 any ideas ?


 --
 View this message in context:
 http://www.nabble.com/triggering-post-of-a-form%2C-from-client-side-tp20699113p20699113.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: Wicket Session grows too big real fast

2008-11-26 Thread John Krasnay
If the previous page is bookmarkable you don't need to keep a reference
to the page instance; instead, just re-create the page parameters and
call setResponsePage(pageClass, parameters) when the user clicks Cancel.

jk

On Wed, Nov 26, 2008 at 01:35:11AM -0800, jhp wrote:
 
 Well, yes references to pages seems to be given as constructor arguments to
 several pages. The idea is that if 'Cancel' is clicked, application goes
 back to previous page. The possibility to go back more than one page is not
 necessary. Is the correct way to implement cancle with some javascript that
 does something like user clicking previous page?
 
 Jukka
 
 
 Martijn Dashorst wrote:
  
  With Wicket 1.3 only one page should be stored in session. You should
  check if you don't keep references between pages - that would result
  in 1+N pages (with N being the number of pages you reference in your
  page).
  
  Other than that: using LDM's and DataView/DataProvider instead of
  ListView will help considerably.
  
  Martijn
  
  
 
 -- 
 View this message in context: 
 http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697523.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]



obtain the wicket-modal id in java code

2008-11-26 Thread Daniele Dellafiore
Hi all.

I want to implement a fade effect for the wicket modal window.
What I miss is the id of the div of the modal that has class=wicket-modal.
The id of that div is generated dynamically. When this happens for a
wicket Component I can get it in the code via the getId method but I
do not have a reference in java code to the wicket-modal as a
component.

I have tryed to understand where the id is generated looking in the
javascript code in ModalWindow class but I am not able to figure out
where the id is generated.

Can anyone help?

Without the id I have to traverse the DOM and this can be difficoult
to do in an easy way for all browser. At least, I think so, I am a
little confused about xpath and javascript that is cross browser, I
accept any kind of advice.

Thanks.

-- 
Daniele Dellafiore
http://blog.ildella.net/

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



Re: Using CompoundPropertyModel with FormComponentPanel

2008-11-26 Thread Ned Collyer

I'm going to be sourcing the labelText from a properties file relatve to the
class of the modelObject (in this case it will be the User - eg,
user.properties).

If I use the binding, then I need to have scope to the CPM in java world...
within the LabelledTextField - which is a shame, because it just makes it
less convenient to use like other regular form components where you do not
have to pass in the model if the form has CPM (eg, standard TextField) 


Nino.Martinez wrote:
 
 Hi Ned
 
 you can call bind on the compound property model..
 
 labelText = new Label(labelText, CPM.bind(propertyname));
 
 You can also do this for your property models btw...
 

-- 
View this message in context: 
http://www.nabble.com/Using-CompoundPropertyModel-with-FormComponentPanel-tp20697019p20699724.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: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

2008-11-26 Thread James Carman
Merely bundling the examples with the code itself shouldn't cause this, do
you think?

On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope 
[EMAIL PROTECTED] wrote:

 YES.
 However I feel people may pass over the earlier branches (especially when
 we're on Wicket version 5.8!) and hence miss some great code that may not
 take much to get working and maintain on the newer branch.

 On Wed, Nov 26, 2008 at 2:06 AM, James Carman [EMAIL PROTECTED]
 wrote:

  Yes, our entire project at work is like this.  The top-level project
  holds multiple modules.  Each has a common, server, and client
  submodule.  Works like a charm.
 
  On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson
  [EMAIL PROTECTED] wrote:
   Great idea!  Yes.  I have not nested any projects three deep in the
 past,
   but it should work.  Has anybody else tried this?
  
   It would be:
  
   wicket-stuff-parent
-- wicket-foo
   -- wicket-foo-core
   -- wicket-foo-examples
  
   On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED]
  wrote:
  
   I don't know if this has already been discussed, but another part of
 the
   cleanup that would be nice is to group the main project and the
 example
   project into a folder with a common parent pom.
  
   For example, I find the layout of:
  
  
 
 https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/
  
   much easier to use/maintain then the apparent standard of
   /wicketstuff-project  /wicketstuff-project-example
  
  
 
 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/
  
   one key thing about this change is that mvn eclipse:eclipse makes the
   example project depend on the core project
  
   perhaps this could be added to the 'organize' task?
  
   ryan
  
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  
   --
   Jeremy Thomerson
   http://www.wickettraining.com
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 



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

2008-11-26 Thread Wayne Pope
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


AutoCompleteTextField - gives a type mismatch error on IE - version wicket-1.4-rc1

2008-11-26 Thread Dipu
wicket-autocomplete.js
function function showAutoComplete()
line 291
container.style.zIndex=(!isNaN(Number(index))?Number(index)+1:index);

looks like IE doesn't like big i in zIndex, IE seem to be be happy with
zindex

not sure if that's the correct way to resolve the issue,  i have attached a
patch though.


Thanks
Dipu
Index: 
src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
===
--- 
src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
 (revision 720770)
+++ 
src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
 (working copy)
@@ -288,7 +288,7 @@
 var input=wicketGet(elementId);
 var index=getOffsetParentZIndex(elementId);
 container.show();
-container.style.zIndex=(!isNaN(Number(index))?Number(index)+1:index);
+container.style.zindex=(!isNaN(Number(index))?Number(index)+1:index);
 container.style.left=position[0]+'px'
 container.style.top=(input.offsetHeight+position[1])+'px';
 if(cfg.adjustInputWidth)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

flash with resource

2008-11-26 Thread tbt

Hi

I am using flash in my web application and currently using the example given
at
http://cwiki.apache.org/WICKET/object-container-adding-flash-to-a-wicket-application.html

This works fine but my swf files are stored in a database and when displayed
now is converted back into a swf file and stored in a temperory folder on
the server. Then the image path is given to the swf file as provided in the
example. But I would like to make this more efficient and like to pass the
swf file stored in the db as a 'Resource'. I currently do this with the
image files stored in the database like

BlobImageResource blobImageResource = new BlobImageResource()
{
@Override
protected Blob getBlob() 
{
return images.getImageFile();
}
};  
Image uploadImage = new Image(uploadImage,blobImageResource);

to display the images in the webpage.

How can I do something similar with the 'ShockWaveComponent' class so that a
'Resource' can be passed as a constructor parameter

Thanks

-- 
View this message in context: 
http://www.nabble.com/flash-with-resource-tp20698407p20698407.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: AutoCompleteTextField - gives a type mismatch error on IE - version wicket-1.4-rc1

2008-11-26 Thread James Carman
The best way would be to file a JIRA (or search for an existing one that
explains this issue) and attach your patch there.  We're not allowed to
apply patches unless they're submitted through JIRA and they have the Grant
license to ASF for inclusion in ASF works thing checked.

On Wed, Nov 26, 2008 at 9:25 AM, Dipu [EMAIL PROTECTED] wrote:

 wicket-autocomplete.js
 function function showAutoComplete()
 line 291
 container.style.zIndex=(!isNaN(Number(index))?Number(index)+1:index);

 looks like IE doesn't like big i in zIndex, IE seem to be be happy with
 zindex

 not sure if that's the correct way to resolve the issue,  i have attached a
 patch though.


 Thanks
 Dipu



 -
 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-26 Thread Hoover, William
I think the idea behind this is that size will be called first. If the
size is zero there is no need to proceed with the call to get the items.
I don't necessarily agree with this approach because a lot of service
calls can capture the data in one call (even down to the database level-
some support getting the size/results in one call), but the last time I
brought this issue up it was disputed.

-Original Message-
From: Wayne Pope [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 26, 2008 9:20 AM
To: users@wicket.apache.org
Subject: Is there any other way? DataProviders must hit the Db twice for
(possible) large datasets

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


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



Re: Wicket Session grows too big real fast

2008-11-26 Thread jhp

Removing references pointing to previous pages solved a lot, very good point.
Also making sure that individual domain objects don't get stored to session
makes  a difference. I have still a lot of code to go through to make sure
that all unnecessary references don't get stored to session, but making a
few changes in the most important pages makes already a big difference.

I noticed that this is a problem that others have experienced too. I guess
it is pretty easy unintentionally stuff the session with domain objects ,and
if using modern day persistence framework, those domain objects can be quite
large if they have collections etc.

I think there is a need for small document outlining the common pitfalls and
remedies for them. I haven't seen such. Wicket reference of course tells
about LoadableDetachableModel, but this thread has info that I haven't found
anywhere else. I might try compose such a document, if I just have the time
and energy in the near future.

Thanks to Martijn, Johan and John for your responses!

BR,
Jukka




Martijn Dashorst wrote:
 
 With Wicket 1.3 only one page should be stored in session. You should
 check if you don't keep references between pages - that would result
 in 1+N pages (with N being the number of pages you reference in your
 page).
 
 Other than that: using LDM's and DataView/DataProvider instead of
 ListView will help considerably.
 
 Martijn
 

-- 
View this message in context: 
http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20702093.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-26 Thread Hoover, William
We use the same workaround :o) 

-Original Message-
From: Michael O'Cleirigh [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 26, 2008 9:43 AM
To: users@wicket.apache.org
Subject: Re: Is there any other way? DataProviders must hit the Db twice
for (possible) large datasets

Hi Wayne,

The way we do it is to only extract the current page from the data
provider once per render cycle.

e.g. the first time size() is called the underlying extraction is
performed to build the list for the size of the current page and all
subsequent calls use this cached value.

You just need to clear the cached state in provider.detach() so that the
next time size() is called (on the next render) the data will be
reloaded properly.

With our project we use the size of the data provider to determine
component visibility (i.e. 0 rows == is visible) which results in alot
more calls of provider.size() but with this caching approach the
rendering performance is not impacted.

Regards,

Mike

 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

   


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



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



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

2008-11-26 Thread Michael O'Cleirigh

Hi Wayne,

The way we do it is to only extract the current page from the data 
provider once per render cycle.


e.g. the first time size() is called the underlying extraction is 
performed to build the list for the size of the current page and all 
subsequent calls use this cached value.


You just need to clear the cached state in provider.detach() so that the 
next time size() is called (on the next render) the data will be 
reloaded properly.


With our project we use the size of the data provider to determine 
component visibility (i.e. 0 rows == is visible) which results in alot 
more calls of provider.size() but with this caching approach the 
rendering performance is not impacted.


Regards,

Mike


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

  



-
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-26 Thread Michael Sparer

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]



Re: Wicket Session grows too big real fast

2008-11-26 Thread Martijn Dashorst
Yes, since the anon-inner class introduces a link between the two.

modify the isVisible() to:

return ((Recommendation)recommendationModel.getObject()).getSupplier() == null;

or rather, implement a method Recommendation
getCurrentRecommendation() { return
((Recommendation)recommendationModel.getObject());}

and use that instead.

Martijn

On Wed, Nov 26, 2008 at 10:52 AM, jhp [EMAIL PROTECTED] wrote:

 In that place, it compiles without it, but I have another class that has
 something like this:
 final Recommendation currentRecommendation = (Recommendation)
 recommendationModel.getObject();
 .
 .
 .
 add(new Label(usersChoice, getUsersChoiceString(name.getFirstname())) {
@Override
public boolean isVisible() {
  return currentRecommendation.getSupplier() != null;
}
 });

 And it doesn't compile without final. so does that mean that this is the
 place which forces the recommendation object to be stored in the session? If
 so, I have to admit that I missed it entirely.

 Jukka


 Johan Compagner wrote:

 if you make this:

  final Recommendation recommendation = (Recommendation)
 item.getModelObject();

 not final does it compile?

 If it doesnt then you have a leak

 johan


 --
 View this message in context: 
 http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697806.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]





-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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



Re: Using CompoundPropertyModel with FormComponentPanel

2008-11-26 Thread Nino Saturnino Martinez Vazquez Wael

ahhh, didnt catch that you were doing that..

Ned Collyer wrote:

I'm going to be sourcing the labelText from a properties file relatve to the
class of the modelObject (in this case it will be the User - eg,
user.properties).

If I use the binding, then I need to have scope to the CPM in java world...
within the LabelledTextField - which is a shame, because it just makes it
less convenient to use like other regular form components where you do not
have to pass in the model if the form has CPM (eg, standard TextField) 



Nino.Martinez wrote:
  

Hi Ned

you can call bind on the compound property model..

labelText = new Label(labelText, CPM.bind(propertyname));

You can also do this for your property models btw...




  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


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



Re: AutoCompleteTextField - gives a type mismatch error on IE - version wicket-1.4-rc1

2008-11-26 Thread Dipu
done https://issues.apache.org/jira/browse/WICKET-1960
https://issues.apache.org/jira/browse/WICKET-1960

On Wed, Nov 26, 2008 at 2:44 PM, James Carman [EMAIL PROTECTED]wrote:

 The best way would be to file a JIRA (or search for an existing one that
 explains this issue) and attach your patch there.  We're not allowed to
 apply patches unless they're submitted through JIRA and they have the
 Grant
 license to ASF for inclusion in ASF works thing checked.

 On Wed, Nov 26, 2008 at 9:25 AM, Dipu [EMAIL PROTECTED] wrote:

  wicket-autocomplete.js
  function function showAutoComplete()
  line 291
  container.style.zIndex=(!isNaN(Number(index))?Number(index)+1:index);
 
  looks like IE doesn't like big i in zIndex, IE seem to be be happy with
  zindex
 
  not sure if that's the correct way to resolve the issue,  i have attached
 a
  patch though.
 
 
  Thanks
  Dipu
 
 
 
  -
  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-26 Thread Wayne Pope
Hi,

thanks for the replies.

Micheal O/Hoover - I still don't see how this works as you don't have the
limit and offset (that is used in Iterator). How do you know how many rows
to load in your size() method?

Michael S - thanks for the link - it it appears I must completely rewrite
the whole pagable/provider code (not looked at the code) to get this to
work?

I'm sure I must be missing something still, as I can't beleive that we need
to either a) load the whole data set b) call count on the Db , then load in
the iterator mehod. Thats going to kill the database in prod (or really not
help.)

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]




Wicket Sesion Size - wiki page

2008-11-26 Thread jWeekend

To get the ball rolling I have created a 
http://cwiki.apache.org/confluence/display/WICKET/Wicket+Session+Size
Wicket Session Size page on the Wiki .

If people would like to contribute I'd say it would probably be best to
start by adding discrete bullet points until we have enough content to
organise into a cohesive and useful document. This will become a valuable
resource s many of you have commented already.

Regards - Cemal
http://www.jWeekend.com http://jWeekend.com 
-- 
View this message in context: 
http://www.nabble.com/Wicket-Sesion-Size---wiki-page-tp20703445p20703445.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]



JUnit testing Image problem

2008-11-26 Thread Nicolas Castin
Hello,

I am writing a JUnit test for a Wicket page containing some images added
dynamically.  My test needs to detect which images as been rendered, but the
org.apache.wicket.markup.html.image.Image class doesn't expose any method to
get it's resource.

I can extend the class to have a public method giving me the resource, but I
can't imagine that there aren't another way to do this.

Thanks for your help.

Nicolas Castin
Senior Software Developer
EURid.eu


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

2008-11-26 Thread James Carman
We just issue a count(*) query first to get the count.  Then, we use
individual queries to get each page's data.  If you feel confident enough
that the count won't change (or you don't really care if it does), you can
cache the value returned from it the count query (I don't know how often
that gets called, really).  If calling the queries to get the individual
page's data is killing your database, then you're doing something wrong,
IMHO.

On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope 
[EMAIL PROTECTED] wrote:

 Hi,

 thanks for the replies.

 Micheal O/Hoover - I still don't see how this works as you don't have the
 limit and offset (that is used in Iterator). How do you know how many rows
 to load in your size() method?

 Michael S - thanks for the link - it it appears I must completely rewrite
 the whole pagable/provider code (not looked at the code) to get this to
 work?

 I'm sure I must be missing something still, as I can't beleive that we need
 to either a) load the whole data set b) call count on the Db , then load in
 the iterator mehod. Thats going to kill the database in prod (or really not
 help.)

 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]
 
 



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

2008-11-26 Thread Wayne Pope
Hi James,

its not killing anything at the moment, I just don't like the idea of
hitting the database with due cause.
However I thinking about this some more I believe perhaps I should not use
DataViews full stop - but RefreshingView instead?. Essentially I have in
several places a large data set. I'm only interested in displaying say the
first 10 rows. Then the user can click on load next 10 and thus display
the next 'page' of results. They then have a choice of loading the next 10
or the previous 10, etc. Perhaps DataView is not really suited to this type
of behaviour? more used where you want to see the number of pages a search
result finds for example? If we're at the edge condition that there are
exactly 20 results, when asking for the next 10, we simply disply the
message 'no more results'.


We just issue a count(*) query first to get the count
Yes so this will be called every time the page is rendered no unless you
cache as you stated, but you run the risk changing dataset?

thanks
Wayne

On Wed, Nov 26, 2008 at 5:05 PM, James Carman [EMAIL PROTECTED]wrote:

 We just issue a count(*) query first to get the count.  Then, we use
 individual queries to get each page's data.  If you feel confident enough
 that the count won't change (or you don't really care if it does), you can
 cache the value returned from it the count query (I don't know how often
 that gets called, really).  If calling the queries to get the individual
 page's data is killing your database, then you're doing something wrong,
 IMHO.

 On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope 
 [EMAIL PROTECTED] wrote:

  Hi,
 
  thanks for the replies.
 
  Micheal O/Hoover - I still don't see how this works as you don't have the
  limit and offset (that is used in Iterator). How do you know how many
 rows
  to load in your size() method?
 
  Michael S - thanks for the link - it it appears I must completely rewrite
  the whole pagable/provider code (not looked at the code) to get this to
  work?
 
  I'm sure I must be missing something still, as I can't beleive that we
 need
  to either a) load the whole data set b) call count on the Db , then load
 in
  the iterator mehod. Thats going to kill the database in prod (or really
 not
  help.)
 
  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]
  
  
 



Re: Wicket Session grows too big real fast

2008-11-26 Thread kan
I am not sure if it always applicable, but usually I do not do
implements Serializable for domain objects (it works well with
Hibernated POJOs). In this case the Wicket cannot serialize a
component, and if it was a link to any such object - wicket just
reports about it into log, so you can see right away which component
has tried to steal a reference to an object (like in your situation
with inner class).

2008/11/26 jhp [EMAIL PROTECTED]:

 Removing references pointing to previous pages solved a lot, very good point.
 Also making sure that individual domain objects don't get stored to session
 makes  a difference. I have still a lot of code to go through to make sure
 that all unnecessary references don't get stored to session, but making a
 few changes in the most important pages makes already a big difference.

 I noticed that this is a problem that others have experienced too. I guess
 it is pretty easy unintentionally stuff the session with domain objects ,and
 if using modern day persistence framework, those domain objects can be quite
 large if they have collections etc.

 I think there is a need for small document outlining the common pitfalls and
 remedies for them. I haven't seen such. Wicket reference of course tells
 about LoadableDetachableModel, but this thread has info that I haven't found
 anywhere else. I might try compose such a document, if I just have the time
 and energy in the near future.

 Thanks to Martijn, Johan and John for your responses!

 BR,
 Jukka




 Martijn Dashorst wrote:

 With Wicket 1.3 only one page should be stored in session. You should
 check if you don't keep references between pages - that would result
 in 1+N pages (with N being the number of pages you reference in your
 page).

 Other than that: using LDM's and DataView/DataProvider instead of
 ListView will help considerably.

 Martijn


 --
 View this message in context: 
 http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20702093.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]





-- 
WBR, kan.

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



Re: Wicket Session grows too big real fast

2008-11-26 Thread Ladislav Thon
Agree. I was almost shocked :-) by Martijn's e-mail about keeping references
between pages. I believed it is a standard practice to keep reference to
previous page for the purpose of cancelling, and of course do it all the
time. It seems very natural to me. O-oops.

LT

2008/11/26 Piller Sébastien [EMAIL PROTECTED]

 I vote for such a document, too. I am now trying to reduce my session size
 too, and if I could find some hints somewhere (ie, be extremly carefull
 with anonymous subclasses, etc) it may be a big plus.

 jhp a écrit :

 Removing references pointing to previous pages solved a lot, very good
 point.
 Also making sure that individual domain objects don't get stored to
 session
 makes  a difference. I have still a lot of code to go through to make sure
 that all unnecessary references don't get stored to session, but making a
 few changes in the most important pages makes already a big difference.

 I noticed that this is a problem that others have experienced too. I guess
 it is pretty easy unintentionally stuff the session with domain objects
 ,and
 if using modern day persistence framework, those domain objects can be
 quite
 large if they have collections etc.

 I think there is a need for small document outlining the common pitfalls
 and
 remedies for them. I haven't seen such. Wicket reference of course tells
 about LoadableDetachableModel, but this thread has info that I haven't
 found
 anywhere else. I might try compose such a document, if I just have the
 time
 and energy in the near future.

 Thanks to Martijn, Johan and John for your responses!

 BR,
 Jukka




 -
 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-26 Thread Matej Knopp
Hi Wayne,

if you feel brave enough you can take a look at inmethod grid
components (available in wicket stuff svn -
http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff  in trunk
and 1.3 branch). The grid contains AbstractPageableView that can
perform paging without having to know the number of rows upfront.

The idea is always to load one row more than required on page which
tells the grid if there will be a next page or not.

-Matej

On Wed, Nov 26, 2008 at 5:15 PM, Wayne Pope
[EMAIL PROTECTED] wrote:
 Hi James,

 its not killing anything at the moment, I just don't like the idea of
 hitting the database with due cause.
 However I thinking about this some more I believe perhaps I should not use
 DataViews full stop - but RefreshingView instead?. Essentially I have in
 several places a large data set. I'm only interested in displaying say the
 first 10 rows. Then the user can click on load next 10 and thus display
 the next 'page' of results. They then have a choice of loading the next 10
 or the previous 10, etc. Perhaps DataView is not really suited to this type
 of behaviour? more used where you want to see the number of pages a search
 result finds for example? If we're at the edge condition that there are
 exactly 20 results, when asking for the next 10, we simply disply the
 message 'no more results'.


We just issue a count(*) query first to get the count
 Yes so this will be called every time the page is rendered no unless you
 cache as you stated, but you run the risk changing dataset?

 thanks
 Wayne

 On Wed, Nov 26, 2008 at 5:05 PM, James Carman [EMAIL PROTECTED]wrote:

 We just issue a count(*) query first to get the count.  Then, we use
 individual queries to get each page's data.  If you feel confident enough
 that the count won't change (or you don't really care if it does), you can
 cache the value returned from it the count query (I don't know how often
 that gets called, really).  If calling the queries to get the individual
 page's data is killing your database, then you're doing something wrong,
 IMHO.

 On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope 
 [EMAIL PROTECTED] wrote:

  Hi,
 
  thanks for the replies.
 
  Micheal O/Hoover - I still don't see how this works as you don't have the
  limit and offset (that is used in Iterator). How do you know how many
 rows
  to load in your size() method?
 
  Michael S - thanks for the link - it it appears I must completely rewrite
  the whole pagable/provider code (not looked at the code) to get this to
  work?
 
  I'm sure I must be missing something still, as I can't beleive that we
 need
  to either a) load the whole data set b) call count on the Db , then load
 in
  the iterator mehod. Thats going to kill the database in prod (or really
 not
  help.)
 
  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]



RES: Wicket Session grows too big real fast

2008-11-26 Thread Bruno Cesar Borges
Now that is a really good advice. :-)

-Mensagem original-
De: kan [mailto:[EMAIL PROTECTED]
Enviada em: quarta-feira, 26 de novembro de 2008 14:19
Para: users@wicket.apache.org
Assunto: Re: Wicket Session grows too big real fast


I am not sure if it always applicable, but usually I do not do
implements Serializable for domain objects (it works well with
Hibernated POJOs). In this case the Wicket cannot serialize a
component, and if it was a link to any such object - wicket just
reports about it into log, so you can see right away which component
has tried to steal a reference to an object (like in your situation
with inner class).

2008/11/26 jhp [EMAIL PROTECTED]:

 Removing references pointing to previous pages solved a lot, very good point.
 Also making sure that individual domain objects don't get stored to session
 makes  a difference. I have still a lot of code to go through to make sure
 that all unnecessary references don't get stored to session, but making a
 few changes in the most important pages makes already a big difference.

 I noticed that this is a problem that others have experienced too. I guess
 it is pretty easy unintentionally stuff the session with domain objects ,and
 if using modern day persistence framework, those domain objects can be quite
 large if they have collections etc.

 I think there is a need for small document outlining the common pitfalls and
 remedies for them. I haven't seen such. Wicket reference of course tells
 about LoadableDetachableModel, but this thread has info that I haven't found
 anywhere else. I might try compose such a document, if I just have the time
 and energy in the near future.

 Thanks to Martijn, Johan and John for your responses!

 BR,
 Jukka




 Martijn Dashorst wrote:

 With Wicket 1.3 only one page should be stored in session. You should
 check if you don't keep references between pages - that would result
 in 1+N pages (with N being the number of pages you reference in your
 page).

 Other than that: using LDM's and DataView/DataProvider instead of
 ListView will help considerably.

 Martijn


 --
 View this message in context: 
 http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20702093.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]





-- 
WBR, kan.

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

***
Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) 
acima identificado(s),
podendo conter informações e/ou documentos confidencias/privilegiados e seu 
sigilo é protegido por 
lei. Caso você tenha recebido por engano, por favor, informe o remetente e 
apague-a de seu sistema.
Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, 
cópia ou uso sem 
expressa autorização do remetente. Opiniões pessoais do remetente não refletem, 
necessariamente, 
o ponto de vista da CETIP, o qual é divulgado somente por pessoas autorizadas.


Warning: This message was sent for exclusive use of the addressees above 
identified, possibly 
containing information and or privileged/confidential documents whose content 
is protected by law. 
In case you have mistakenly received it, please notify the sender and delete it 
from your system. 
Be noticed that the law forbids the retention, dissemination, distribution, 
copy or use without 
express authorization from the sender. Personal opinions of the sender do not 
necessarily reflect 
CETIP's point of view, which is only divulged by authorized personnel.
***


RES: Wicket Session grows too big real fast

2008-11-26 Thread Bruno Cesar Borges
Maybe would be a good idea if Wicket could report memory usage for 
non-Wicket_Components (and non-standard Java objects, like String and 
Collections) in memory. I don't know if this could ever be possible.

-Mensagem original-
De: Ladislav Thon [mailto:[EMAIL PROTECTED]
Enviada em: quarta-feira, 26 de novembro de 2008 14:21
Para: users@wicket.apache.org
Assunto: Re: Wicket Session grows too big real fast


Agree. I was almost shocked :-) by Martijn's e-mail about keeping references
between pages. I believed it is a standard practice to keep reference to
previous page for the purpose of cancelling, and of course do it all the
time. It seems very natural to me. O-oops.

LT

2008/11/26 Piller Sébastien [EMAIL PROTECTED]

 I vote for such a document, too. I am now trying to reduce my session size
 too, and if I could find some hints somewhere (ie, be extremly carefull
 with anonymous subclasses, etc) it may be a big plus.

 jhp a écrit :

 Removing references pointing to previous pages solved a lot, very good
 point.
 Also making sure that individual domain objects don't get stored to
 session
 makes  a difference. I have still a lot of code to go through to make sure
 that all unnecessary references don't get stored to session, but making a
 few changes in the most important pages makes already a big difference.

 I noticed that this is a problem that others have experienced too. I guess
 it is pretty easy unintentionally stuff the session with domain objects
 ,and
 if using modern day persistence framework, those domain objects can be
 quite
 large if they have collections etc.

 I think there is a need for small document outlining the common pitfalls
 and
 remedies for them. I haven't seen such. Wicket reference of course tells
 about LoadableDetachableModel, but this thread has info that I haven't
 found
 anywhere else. I might try compose such a document, if I just have the
 time
 and energy in the near future.

 Thanks to Martijn, Johan and John for your responses!

 BR,
 Jukka




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


***
Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) 
acima identificado(s),
podendo conter informações e/ou documentos confidencias/privilegiados e seu 
sigilo é protegido por 
lei. Caso você tenha recebido por engano, por favor, informe o remetente e 
apague-a de seu sistema.
Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, 
cópia ou uso sem 
expressa autorização do remetente. Opiniões pessoais do remetente não refletem, 
necessariamente, 
o ponto de vista da CETIP, o qual é divulgado somente por pessoas autorizadas.


Warning: This message was sent for exclusive use of the addressees above 
identified, possibly 
containing information and or privileged/confidential documents whose content 
is protected by law. 
In case you have mistakenly received it, please notify the sender and delete it 
from your system. 
Be noticed that the law forbids the retention, dissemination, distribution, 
copy or use without 
express authorization from the sender. Personal opinions of the sender do not 
necessarily reflect 
CETIP's point of view, which is only divulged by authorized personnel.
***


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



continueToOriginalDestination and POST

2008-11-26 Thread kan
I have a site which requires authentication. I've made it via
@AuthorizeInstantiation.
Works well. But if a bookmarkable page has a form with method POST,
and user presses submit after timeout, it redirects him to SignIn
screen. After successful login the site redirects back (usinig
continueToOriginalDestination) to the page and happens not very good
thing - method on form onSubmit is called but with no data on it,
because POST is lost during that redirects. Is there any easy reliable
solution of the problem?

-- 
WBR, kan.

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



Re: AutoCompleteTextField - gives a type mismatch error on IE - version wicket-1.4-rc1

2008-11-26 Thread Jeremy Thomerson
This is fixed in trunk - I just ran into the same yesterday.  Upgraded from
rc1 to snapshot and it's working.

-- 
Jeremy Thomerson
http://www.wickettraining.com



On Wed, Nov 26, 2008 at 9:32 AM, Dipu [EMAIL PROTECTED] wrote:

 done https://issues.apache.org/jira/browse/WICKET-1960
 https://issues.apache.org/jira/browse/WICKET-1960

 On Wed, Nov 26, 2008 at 2:44 PM, James Carman [EMAIL PROTECTED]
 wrote:

  The best way would be to file a JIRA (or search for an existing one that
  explains this issue) and attach your patch there.  We're not allowed to
  apply patches unless they're submitted through JIRA and they have the
  Grant
  license to ASF for inclusion in ASF works thing checked.
 
  On Wed, Nov 26, 2008 at 9:25 AM, Dipu [EMAIL PROTECTED] wrote:
 
   wicket-autocomplete.js
   function function showAutoComplete()
   line 291
   container.style.zIndex=(!isNaN(Number(index))?Number(index)+1:index);
  
   looks like IE doesn't like big i in zIndex, IE seem to be be happy with
   zindex
  
   not sure if that's the correct way to resolve the issue,  i have
 attached
  a
   patch though.
  
  
   Thanks
   Dipu
  
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
 



Re: continueToOriginalDestination and POST

2008-11-26 Thread Jeremy Thomerson
They shouldn't be able to access the bookmarkable page with the form (or,
access the page, but have the form hidden until signed-in).  For
continueToOriginalDestination, IIRC, Wicket just stores the URL, so you
can't go back to a POST.

On Wed, Nov 26, 2008 at 10:27 AM, kan [EMAIL PROTECTED] wrote:

 I have a site which requires authentication. I've made it via
 @AuthorizeInstantiation.
 Works well. But if a bookmarkable page has a form with method POST,
 and user presses submit after timeout, it redirects him to SignIn
 screen. After successful login the site redirects back (usinig
 continueToOriginalDestination) to the page and happens not very good
 thing - method on form onSubmit is called but with no data on it,
 because POST is lost during that redirects. Is there any easy reliable
 solution of the problem?

 --
 WBR, kan.

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




-- 
Jeremy Thomerson
http://www.wickettraining.com


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

2008-11-26 Thread James Carman
Or there's that! :)


On Wed, Nov 26, 2008 at 11:21 AM, Matej Knopp [EMAIL PROTECTED] wrote:

 Hi Wayne,

 if you feel brave enough you can take a look at inmethod grid
 components (available in wicket stuff svn -
 http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff  in trunk
 and 1.3 branch). The grid contains AbstractPageableView that can
 perform paging without having to know the number of rows upfront.

 The idea is always to load one row more than required on page which
 tells the grid if there will be a next page or not.

 -Matej

 On Wed, Nov 26, 2008 at 5:15 PM, Wayne Pope
 [EMAIL PROTECTED] wrote:
  Hi James,
 
  its not killing anything at the moment, I just don't like the idea of
  hitting the database with due cause.
  However I thinking about this some more I believe perhaps I should not
 use
  DataViews full stop - but RefreshingView instead?. Essentially I have in
  several places a large data set. I'm only interested in displaying say
 the
  first 10 rows. Then the user can click on load next 10 and thus display
  the next 'page' of results. They then have a choice of loading the next
 10
  or the previous 10, etc. Perhaps DataView is not really suited to this
 type
  of behaviour? more used where you want to see the number of pages a
 search
  result finds for example? If we're at the edge condition that there are
  exactly 20 results, when asking for the next 10, we simply disply the
  message 'no more results'.
 
 
 We just issue a count(*) query first to get the count
  Yes so this will be called every time the page is rendered no unless you
  cache as you stated, but you run the risk changing dataset?
 
  thanks
  Wayne
 
  On Wed, Nov 26, 2008 at 5:05 PM, James Carman 
 [EMAIL PROTECTED]wrote:
 
  We just issue a count(*) query first to get the count.  Then, we use
  individual queries to get each page's data.  If you feel confident
 enough
  that the count won't change (or you don't really care if it does), you
 can
  cache the value returned from it the count query (I don't know how often
  that gets called, really).  If calling the queries to get the individual
  page's data is killing your database, then you're doing something wrong,
  IMHO.
 
  On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope 
  [EMAIL PROTECTED] wrote:
 
   Hi,
  
   thanks for the replies.
  
   Micheal O/Hoover - I still don't see how this works as you don't have
 the
   limit and offset (that is used in Iterator). How do you know how many
  rows
   to load in your size() method?
  
   Michael S - thanks for the link - it it appears I must completely
 rewrite
   the whole pagable/provider code (not looked at the code) to get this
 to
   work?
  
   I'm sure I must be missing something still, as I can't beleive that we
  need
   to either a) load the whole data set b) call count on the Db , then
 load
  in
   the iterator mehod. Thats going to kill the database in prod (or
 really
  not
   help.)
  
   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]




Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

2008-11-26 Thread Jeremy Thomerson
I think Wayne was referring not to your post, but in general - if we package
most of the projects up neatly under one parent, then other projects that
aren't in the same subdirectory / build cycle may get lost.

I don't see this as too much of an issue - a project's visibility will come
from a) it's documentation on wicketstuff.org or b) it's userbase talking
about it on the user list.  Typically, browsing the SVN tree isn't the way
we find projects.
-- 
Jeremy Thomerson
http://www.wickettraining.com


On Wed, Nov 26, 2008 at 7:10 AM, James Carman [EMAIL PROTECTED]wrote:

 Merely bundling the examples with the code itself shouldn't cause this,
 do
 you think?

 On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope 
 [EMAIL PROTECTED] wrote:

  YES.
  However I feel people may pass over the earlier branches (especially when
  we're on Wicket version 5.8!) and hence miss some great code that may not
  take much to get working and maintain on the newer branch.
 
  On Wed, Nov 26, 2008 at 2:06 AM, James Carman 
 [EMAIL PROTECTED]
  wrote:
 
   Yes, our entire project at work is like this.  The top-level project
   holds multiple modules.  Each has a common, server, and client
   submodule.  Works like a charm.
  
   On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson
   [EMAIL PROTECTED] wrote:
Great idea!  Yes.  I have not nested any projects three deep in the
  past,
but it should work.  Has anybody else tried this?
   
It would be:
   
wicket-stuff-parent
 -- wicket-foo
-- wicket-foo-core
-- wicket-foo-examples
   
On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED]
   wrote:
   
I don't know if this has already been discussed, but another part of
  the
cleanup that would be nice is to group the main project and the
  example
project into a folder with a common parent pom.
   
For example, I find the layout of:
   
   
  
 
 https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/
   
much easier to use/maintain then the apparent standard of
/wicketstuff-project  /wicketstuff-project-example
   
   
  
 
 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/
   
one key thing about this change is that mvn eclipse:eclipse makes
 the
example project depend on the core project
   
perhaps this could be added to the 'organize' task?
   
ryan
   
   
   
   
 -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
   
   
--
Jeremy Thomerson
http://www.wickettraining.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-26 Thread Wayne Pope
Hi Matej,

The idea is always to load one row more than required on page which
tells the grid if there will be a next page or not.

Great idea. I looked at the code and I think I'll do my own (simplied
version) of your refreashingpage. I believe thats what we really want here,
as we don't care about telling the user the total amount of rows.

Thanks everyone for your comments and help
Wayne

On Wed, Nov 26, 2008 at 5:21 PM, Matej Knopp [EMAIL PROTECTED] wrote:

 Hi Wayne,

 if you feel brave enough you can take a look at inmethod grid
 components (available in wicket stuff svn -
 http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff  in trunk
 and 1.3 branch). The grid contains AbstractPageableView that can
 perform paging without having to know the number of rows upfront.

 The idea is always to load one row more than required on page which
 tells the grid if there will be a next page or not.

 -Matej

 On Wed, Nov 26, 2008 at 5:15 PM, Wayne Pope
 [EMAIL PROTECTED] wrote:
  Hi James,
 
  its not killing anything at the moment, I just don't like the idea of
  hitting the database with due cause.
  However I thinking about this some more I believe perhaps I should not
 use
  DataViews full stop - but RefreshingView instead?. Essentially I have in
  several places a large data set. I'm only interested in displaying say
 the
  first 10 rows. Then the user can click on load next 10 and thus display
  the next 'page' of results. They then have a choice of loading the next
 10
  or the previous 10, etc. Perhaps DataView is not really suited to this
 type
  of behaviour? more used where you want to see the number of pages a
 search
  result finds for example? If we're at the edge condition that there are
  exactly 20 results, when asking for the next 10, we simply disply the
  message 'no more results'.
 
 
 We just issue a count(*) query first to get the count
  Yes so this will be called every time the page is rendered no unless you
  cache as you stated, but you run the risk changing dataset?
 
  thanks
  Wayne
 
  On Wed, Nov 26, 2008 at 5:05 PM, James Carman 
 [EMAIL PROTECTED]wrote:
 
  We just issue a count(*) query first to get the count.  Then, we use
  individual queries to get each page's data.  If you feel confident
 enough
  that the count won't change (or you don't really care if it does), you
 can
  cache the value returned from it the count query (I don't know how often
  that gets called, really).  If calling the queries to get the individual
  page's data is killing your database, then you're doing something wrong,
  IMHO.
 
  On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope 
  [EMAIL PROTECTED] wrote:
 
   Hi,
  
   thanks for the replies.
  
   Micheal O/Hoover - I still don't see how this works as you don't have
 the
   limit and offset (that is used in Iterator). How do you know how many
  rows
   to load in your size() method?
  
   Michael S - thanks for the link - it it appears I must completely
 rewrite
   the whole pagable/provider code (not looked at the code) to get this
 to
   work?
  
   I'm sure I must be missing something still, as I can't beleive that we
  need
   to either a) load the whole data set b) call count on the Db , then
 load
  in
   the iterator mehod. Thats going to kill the database in prod (or
 really
  not
   help.)
  
   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]




Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

2008-11-26 Thread James Carman
On Wed, Nov 26, 2008 at 11:38 AM, Jeremy Thomerson 
[EMAIL PROTECTED] wrote:

 I think Wayne was referring not to your post, but in general - if we
 package
 most of the projects up neatly under one parent, then other projects that
 aren't in the same subdirectory / build cycle may get lost.

 I don't see this as too much of an issue - a project's visibility will come
 from a) it's documentation on wicketstuff.org or b) it's userbase talking
 about it on the user list.  Typically, browsing the SVN tree isn't the way
 we find projects.


Agreed!  Now, the only issue is beefing up the documentation on
wicketstuff.org.  I've found that it's very difficult to find what I'm
looking for up there.


Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

2008-11-26 Thread Martijn Dashorst
On Wed, Nov 26, 2008 at 5:38 PM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
 Typically, browsing the SVN tree isn't the way we find projects.

Talk for yourself :)

Martijn

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



Re: AutoCompleteTextField - gives a type mismatch error on IE - version wicket-1.4-rc1

2008-11-26 Thread Dipu
In the current trunk,  it's reverted back
to container.style.zIndex=(Number(index)!=Number.NaN?Number(index)+1:index);
 and
it works,
but its working because some thing else is broken

when the value of  index ='auto';
the expression  (Number(index)!=Number.NaN?Number(index)+1:index);  return
NaN,
this looks wrong to me it should be returning 'auto'

for example if you run the following line in javascript console in firebug
you will get NaN
var index ='auto';(Number(index)!=Number.NaN?Number(index)+1:index)
if you run Number(index) it return NaN

but Number(index)!=Number.NaN yields true (looks wrong to me)

just my 2 cents

Cheers
Dipu





On Wed, Nov 26, 2008 at 4:29 PM, Jeremy Thomerson [EMAIL PROTECTED]
 wrote:

 This is fixed in trunk - I just ran into the same yesterday.  Upgraded from
 rc1 to snapshot and it's working.

 --
 Jeremy Thomerson
 http://www.wickettraining.com



 On Wed, Nov 26, 2008 at 9:32 AM, Dipu [EMAIL PROTECTED] wrote:

  done https://issues.apache.org/jira/browse/WICKET-1960
  https://issues.apache.org/jira/browse/WICKET-1960
 
  On Wed, Nov 26, 2008 at 2:44 PM, James Carman 
 [EMAIL PROTECTED]
  wrote:
 
   The best way would be to file a JIRA (or search for an existing one
 that
   explains this issue) and attach your patch there.  We're not allowed to
   apply patches unless they're submitted through JIRA and they have the
   Grant
   license to ASF for inclusion in ASF works thing checked.
  
   On Wed, Nov 26, 2008 at 9:25 AM, Dipu [EMAIL PROTECTED] wrote:
  
wicket-autocomplete.js
function function showAutoComplete()
line 291
container.style.zIndex=(!isNaN(Number(index))?Number(index)+1:index);
   
looks like IE doesn't like big i in zIndex, IE seem to be be happy
 with
zindex
   
not sure if that's the correct way to resolve the issue,  i have
  attached
   a
patch though.
   
   
Thanks
Dipu
   
   
   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
  
 



Re: Wicket Session grows too big real fast

2008-11-26 Thread James Carman
Not exactly.   It might be okay for web projects like this, but if you need
to do any remoting, this won't work.  Our domain entities have to be
serializable.

On Wed, Nov 26, 2008 at 11:22 AM, Bruno Cesar Borges 
[EMAIL PROTECTED] wrote:

 Now that is a really good advice. :-)

 -Mensagem original-
 De: kan [mailto:[EMAIL PROTECTED]
 Enviada em: quarta-feira, 26 de novembro de 2008 14:19
 Para: users@wicket.apache.org
 Assunto: Re: Wicket Session grows too big real fast


 I am not sure if it always applicable, but usually I do not do
 implements Serializable for domain objects (it works well with
 Hibernated POJOs). In this case the Wicket cannot serialize a
 component, and if it was a link to any such object - wicket just
 reports about it into log, so you can see right away which component
 has tried to steal a reference to an object (like in your situation
 with inner class).

 2008/11/26 jhp [EMAIL PROTECTED]:
 
  Removing references pointing to previous pages solved a lot, very good
 point.
  Also making sure that individual domain objects don't get stored to
 session
  makes  a difference. I have still a lot of code to go through to make
 sure
  that all unnecessary references don't get stored to session, but making a
  few changes in the most important pages makes already a big difference.
 
  I noticed that this is a problem that others have experienced too. I
 guess
  it is pretty easy unintentionally stuff the session with domain objects
 ,and
  if using modern day persistence framework, those domain objects can be
 quite
  large if they have collections etc.
 
  I think there is a need for small document outlining the common pitfalls
 and
  remedies for them. I haven't seen such. Wicket reference of course tells
  about LoadableDetachableModel, but this thread has info that I haven't
 found
  anywhere else. I might try compose such a document, if I just have the
 time
  and energy in the near future.
 
  Thanks to Martijn, Johan and John for your responses!
 
  BR,
  Jukka
 
 
 
 
  Martijn Dashorst wrote:
 
  With Wicket 1.3 only one page should be stored in session. You should
  check if you don't keep references between pages - that would result
  in 1+N pages (with N being the number of pages you reference in your
  page).
 
  Other than that: using LDM's and DataView/DataProvider instead of
  ListView will help considerably.
 
  Martijn
 
 
  --
  View this message in context:
 http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20702093.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]
 
 



 --
 WBR, kan.

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


 ***
 Atenção: Esta mensagem foi enviada para uso exclusivo do(s)
 destinatários(s) acima identificado(s),
 podendo conter informações e/ou documentos confidencias/privilegiados e seu
 sigilo é protegido por
 lei. Caso você tenha recebido por engano, por favor, informe o remetente e
 apague-a de seu sistema.
 Notificamos que é proibido por lei a sua retenção, disseminação,
 distribuição, cópia ou uso sem
 expressa autorização do remetente. Opiniões pessoais do remetente não
 refletem, necessariamente,
 o ponto de vista da CETIP, o qual é divulgado somente por pessoas
 autorizadas.


 Warning: This message was sent for exclusive use of the addressees above
 identified, possibly
 containing information and or privileged/confidential documents whose
 content is protected by law.
 In case you have mistakenly received it, please notify the sender and
 delete it from your system.
 Be noticed that the law forbids the retention, dissemination, distribution,
 copy or use without
 express authorization from the sender. Personal opinions of the sender do
 not necessarily reflect
 CETIP's point of view, which is only divulged by authorized personnel.

 ***



Re: AutoCompleteTextField - gives a type mismatch error on IE - version wicket-1.4-rc1

2008-11-26 Thread Jeremy Thomerson
Wow!  Thanks!  Good to know since I need to release an app today on a
modified version of rc1 just because of this app.  I didn't look into it any
more last night after changing to snapshot and seeing it work.

Thanks again,

Jeremy Thomerson
http://www.wickettraining.com


On Wed, Nov 26, 2008 at 10:48 AM, Dipu [EMAIL PROTECTED] wrote:

 In the current trunk,  it's reverted back
 to
 container.style.zIndex=(Number(index)!=Number.NaN?Number(index)+1:index);
  and
 it works,
 but its working because some thing else is broken

 when the value of  index ='auto';
 the expression  (Number(index)!=Number.NaN?Number(index)+1:index);  return
 NaN,
 this looks wrong to me it should be returning 'auto'

 for example if you run the following line in javascript console in firebug
 you will get NaN
 var index ='auto';(Number(index)!=Number.NaN?Number(index)+1:index)
 if you run Number(index) it return NaN

 but Number(index)!=Number.NaN yields true (looks wrong to me)

 just my 2 cents

 Cheers
 Dipu





 On Wed, Nov 26, 2008 at 4:29 PM, Jeremy Thomerson 
 [EMAIL PROTECTED]
  wrote:

  This is fixed in trunk - I just ran into the same yesterday.  Upgraded
 from
  rc1 to snapshot and it's working.
 
  --
  Jeremy Thomerson
  http://www.wickettraining.com
 
 
 
  On Wed, Nov 26, 2008 at 9:32 AM, Dipu [EMAIL PROTECTED] wrote:
 
   done https://issues.apache.org/jira/browse/WICKET-1960
   https://issues.apache.org/jira/browse/WICKET-1960
  
   On Wed, Nov 26, 2008 at 2:44 PM, James Carman 
  [EMAIL PROTECTED]
   wrote:
  
The best way would be to file a JIRA (or search for an existing one
  that
explains this issue) and attach your patch there.  We're not allowed
 to
apply patches unless they're submitted through JIRA and they have the
Grant
license to ASF for inclusion in ASF works thing checked.
   
On Wed, Nov 26, 2008 at 9:25 AM, Dipu [EMAIL PROTECTED]
 wrote:
   
 wicket-autocomplete.js
 function function showAutoComplete()
 line 291

 container.style.zIndex=(!isNaN(Number(index))?Number(index)+1:index);

 looks like IE doesn't like big i in zIndex, IE seem to be be happy
  with
 zindex

 not sure if that's the correct way to resolve the issue,  i have
   attached
a
 patch though.


 Thanks
 Dipu




 -
 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-26 Thread Matej Knopp
You can just take AbstractPageableView, IDataSource and IGridSortState
from the code. It should do exactly what you want and It shouldn't
have any dependencies on the rest of grids.

-Matej

On Wed, Nov 26, 2008 at 5:39 PM, Wayne Pope
[EMAIL PROTECTED] wrote:
 Hi Matej,

The idea is always to load one row more than required on page which
tells the grid if there will be a next page or not.

 Great idea. I looked at the code and I think I'll do my own (simplied
 version) of your refreashingpage. I believe thats what we really want here,
 as we don't care about telling the user the total amount of rows.

 Thanks everyone for your comments and help
 Wayne

 On Wed, Nov 26, 2008 at 5:21 PM, Matej Knopp [EMAIL PROTECTED] wrote:

 Hi Wayne,

 if you feel brave enough you can take a look at inmethod grid
 components (available in wicket stuff svn -
 http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff  in trunk
 and 1.3 branch). The grid contains AbstractPageableView that can
 perform paging without having to know the number of rows upfront.

 The idea is always to load one row more than required on page which
 tells the grid if there will be a next page or not.

 -Matej

 On Wed, Nov 26, 2008 at 5:15 PM, Wayne Pope
 [EMAIL PROTECTED] wrote:
  Hi James,
 
  its not killing anything at the moment, I just don't like the idea of
  hitting the database with due cause.
  However I thinking about this some more I believe perhaps I should not
 use
  DataViews full stop - but RefreshingView instead?. Essentially I have in
  several places a large data set. I'm only interested in displaying say
 the
  first 10 rows. Then the user can click on load next 10 and thus display
  the next 'page' of results. They then have a choice of loading the next
 10
  or the previous 10, etc. Perhaps DataView is not really suited to this
 type
  of behaviour? more used where you want to see the number of pages a
 search
  result finds for example? If we're at the edge condition that there are
  exactly 20 results, when asking for the next 10, we simply disply the
  message 'no more results'.
 
 
 We just issue a count(*) query first to get the count
  Yes so this will be called every time the page is rendered no unless you
  cache as you stated, but you run the risk changing dataset?
 
  thanks
  Wayne
 
  On Wed, Nov 26, 2008 at 5:05 PM, James Carman 
 [EMAIL PROTECTED]wrote:
 
  We just issue a count(*) query first to get the count.  Then, we use
  individual queries to get each page's data.  If you feel confident
 enough
  that the count won't change (or you don't really care if it does), you
 can
  cache the value returned from it the count query (I don't know how often
  that gets called, really).  If calling the queries to get the individual
  page's data is killing your database, then you're doing something wrong,
  IMHO.
 
  On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope 
  [EMAIL PROTECTED] wrote:
 
   Hi,
  
   thanks for the replies.
  
   Micheal O/Hoover - I still don't see how this works as you don't have
 the
   limit and offset (that is used in Iterator). How do you know how many
  rows
   to load in your size() method?
  
   Michael S - thanks for the link - it it appears I must completely
 rewrite
   the whole pagable/provider code (not looked at the code) to get this
 to
   work?
  
   I'm sure I must be missing something still, as I can't beleive that we
  need
   to either a) load the whole data set b) call count on the Db , then
 load
  in
   the iterator mehod. Thats going to kill the database in prod (or
 really
  not
   help.)
  
   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 

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

2008-11-26 Thread Igor Vaynberg
On Wed, Nov 26, 2008 at 7:32 AM, Wayne Pope
[EMAIL PROTECTED] wrote:
 I'm sure I must be missing something still, as I can't beleive that we need
 to either a) load the whole data set

what? why would you ever load the whole dataset?

b) call count on the Db , then load in
 the iterator mehod. Thats going to kill the database in prod (or really not
 help.)

yeah. because select count() queries are the most expensive queries
you can run on the database. you are right, its totally going to kill
it. you know how all those sites 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]



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

2008-11-26 Thread James Carman
You've overloaded my sarcasm meter!  Darn it, now I have to go buy a new
one.

On Wed, Nov 26, 2008 at 11:58 AM, Igor Vaynberg [EMAIL PROTECTED]wrote:

 On Wed, Nov 26, 2008 at 7:32 AM, Wayne Pope
 [EMAIL PROTECTED] wrote:
  I'm sure I must be missing something still, as I can't beleive that we
 need
  to either a) load the whole data set

 what? why would you ever load the whole dataset?

 b) call count on the Db , then load in
  the iterator mehod. Thats going to kill the database in prod (or really
 not
  help.)

 yeah. because select count() queries are the most expensive queries
 you can run on the database. you are right, its totally going to kill
 it. you know how all those sites 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]




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

2008-11-26 Thread Wayne Pope
Thanks Matej,

I just noticed org.apache.wicket.markup.repeater.AbstractPageableViewT
which seems what I'm ofter - I'll have a look and both and get something
working.


On Wed, Nov 26, 2008 at 5:57 PM, Matej Knopp [EMAIL PROTECTED] wrote:

 You can just take AbstractPageableView, IDataSource and IGridSortState
 from the code. It should do exactly what you want and It shouldn't
 have any dependencies on the rest of grids.

 -Matej

 On Wed, Nov 26, 2008 at 5:39 PM, Wayne Pope
 [EMAIL PROTECTED] wrote:
  Hi Matej,
 
 The idea is always to load one row more than required on page which
 tells the grid if there will be a next page or not.
 
  Great idea. I looked at the code and I think I'll do my own (simplied
  version) of your refreashingpage. I believe thats what we really want
 here,
  as we don't care about telling the user the total amount of rows.
 
  Thanks everyone for your comments and help
  Wayne
 
  On Wed, Nov 26, 2008 at 5:21 PM, Matej Knopp [EMAIL PROTECTED]
 wrote:
 
  Hi Wayne,
 
  if you feel brave enough you can take a look at inmethod grid
  components (available in wicket stuff svn -
  http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff  in trunk
  and 1.3 branch). The grid contains AbstractPageableView that can
  perform paging without having to know the number of rows upfront.
 
  The idea is always to load one row more than required on page which
  tells the grid if there will be a next page or not.
 
  -Matej
 
  On Wed, Nov 26, 2008 at 5:15 PM, Wayne Pope
  [EMAIL PROTECTED] wrote:
   Hi James,
  
   its not killing anything at the moment, I just don't like the idea of
   hitting the database with due cause.
   However I thinking about this some more I believe perhaps I should not
  use
   DataViews full stop - but RefreshingView instead?. Essentially I have
 in
   several places a large data set. I'm only interested in displaying say
  the
   first 10 rows. Then the user can click on load next 10 and thus
 display
   the next 'page' of results. They then have a choice of loading the
 next
  10
   or the previous 10, etc. Perhaps DataView is not really suited to this
  type
   of behaviour? more used where you want to see the number of pages a
  search
   result finds for example? If we're at the edge condition that there
 are
   exactly 20 results, when asking for the next 10, we simply disply the
   message 'no more results'.
  
  
  We just issue a count(*) query first to get the count
   Yes so this will be called every time the page is rendered no unless
 you
   cache as you stated, but you run the risk changing dataset?
  
   thanks
   Wayne
  
   On Wed, Nov 26, 2008 at 5:05 PM, James Carman 
  [EMAIL PROTECTED]wrote:
  
   We just issue a count(*) query first to get the count.  Then, we use
   individual queries to get each page's data.  If you feel confident
  enough
   that the count won't change (or you don't really care if it does),
 you
  can
   cache the value returned from it the count query (I don't know how
 often
   that gets called, really).  If calling the queries to get the
 individual
   page's data is killing your database, then you're doing something
 wrong,
   IMHO.
  
   On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope 
   [EMAIL PROTECTED] wrote:
  
Hi,
   
thanks for the replies.
   
Micheal O/Hoover - I still don't see how this works as you don't
 have
  the
limit and offset (that is used in Iterator). How do you know how
 many
   rows
to load in your size() method?
   
Michael S - thanks for the link - it it appears I must completely
  rewrite
the whole pagable/provider code (not looked at the code) to get
 this
  to
work?
   
I'm sure I must be missing something still, as I can't beleive that
 we
   need
to either a) load the whole data set b) call count on the Db , then
  load
   in
the iterator mehod. Thats going to kill the database in prod (or
  really
   not
help.)
   
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 

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

2008-11-26 Thread Wayne Pope
Hi Igor,

what? why would you ever load the whole dataset?
just to avoid 2 calls on smallish datasets, especially when there are
multiple joins and database isnt on the same box.

yeah. because select count() queries are the most expensive queries
you can run on the database. you are right, its totally going to kill
it. you know how all those sites 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()?

Ouch.
I just want to limit calls if possible to the database as waiting for i/o's
is never great for scalability. I'm not 'having a go' at wicket or DataViews
or anything, just trying to understand it. I never claimed to be a guru -
far from it.

Wayne


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

 On Wed, Nov 26, 2008 at 7:32 AM, Wayne Pope
 [EMAIL PROTECTED] wrote:
  I'm sure I must be missing something still, as I can't beleive that we
 need
  to either a) load the whole data set

 what? why would you ever load the whole dataset?

 b) call count on the Db , then load in
  the iterator mehod. Thats going to kill the database in prod (or really
 not
  help.)

 yeah. because select count() queries are the most expensive queries
 you can run on the database. you are right, its totally going to kill
 it. you know how all those sites 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]




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

2008-11-26 Thread Igor Vaynberg
On Wed, Nov 26, 2008 at 9:06 AM, Wayne Pope
[EMAIL PROTECTED] wrote:
 Hi Igor,

what? why would you ever load the whole dataset?
 just to avoid 2 calls on smallish datasets, especially when there are
 multiple joins and database isnt on the same box.

so you think pushing all that extra data over the network is actually
more efficient then doing another query wtf.

yeah. because select count() queries are the most expensive queries
you can run on the database. you are right, its totally going to kill
it. you know how all those sites 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()?

 Ouch.
 I just want to limit calls if possible to the database as waiting for i/o's
 is never great for scalability. I'm not 'having a go' at wicket or DataViews
 or anything, just trying to understand it. I never claimed to be a guru -
 far from it.

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?

-igor


 Wayne


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

 On Wed, Nov 26, 2008 at 7:32 AM, Wayne Pope
 [EMAIL PROTECTED] wrote:
  I'm sure I must be missing something still, as I can't beleive that we
 need
  to either a) load the whole data set

 what? why would you ever load the whole dataset?

 b) call count on the Db , then load in
  the iterator mehod. Thats going to kill the database in prod (or really
 not
  help.)

 yeah. because select count() queries are the most expensive queries
 you can run on the database. you are right, its totally going to kill
 it. you know how all those sites 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]



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

2008-11-26 Thread Bruno Cesar Borges
You have to consider some things

1) Is this table going to be huge?
2) Am I going to let users do a Full Table Scan? (letting them search without 
filters, for instance)
3) Is this table frequently updated? How often new data is added to it?
4) Any other question that may affect your scalability ...

Then you will know if is a good idea to just bring the whole data, or do a 
count(*) before.

But, from my experience I rather say: always do a count(*) before.

Regards,
Bruno

-Mensagem original-
De: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Enviada em: quarta-feira, 26 de novembro de 2008 15:20
Para: users@wicket.apache.org
Assunto: Re: Is there any other way? DataProviders must hit the Db twice
for (possible) large datasets


On Wed, Nov 26, 2008 at 9:06 AM, Wayne Pope
[EMAIL PROTECTED] wrote:
 Hi Igor,

what? why would you ever load the whole dataset?
 just to avoid 2 calls on smallish datasets, especially when there are
 multiple joins and database isnt on the same box.

so you think pushing all that extra data over the network is actually
more efficient then doing another query wtf.

yeah. because select count() queries are the most expensive queries
you can run on the database. you are right, its totally going to kill
it. you know how all those sites 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()?

 Ouch.
 I just want to limit calls if possible to the database as waiting for i/o's
 is never great for scalability. I'm not 'having a go' at wicket or DataViews
 or anything, just trying to understand it. I never claimed to be a guru -
 far from it.

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?

-igor


 Wayne


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

 On Wed, Nov 26, 2008 at 7:32 AM, Wayne Pope
 [EMAIL PROTECTED] wrote:
  I'm sure I must be missing something still, as I can't beleive that we
 need
  to either a) load the whole data set

 what? why would you ever load the whole dataset?

 b) call count on the Db , then load in
  the iterator mehod. Thats going to kill the database in prod (or really
 not
  help.)

 yeah. because select count() queries are the most expensive queries
 you can run on the database. you are right, its totally going to kill
 it. you know how all those sites 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]

***
Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) 
acima identificado(s),
podendo conter informações e/ou documentos confidencias/privilegiados e seu 
sigilo é protegido por 
lei. Caso você tenha recebido por engano, por favor, informe o remetente e 
apague-a de seu sistema.
Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, 
cópia ou uso sem 
expressa autorização do 

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

2008-11-26 Thread Wayne Pope
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.

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 AM, Wayne Pope
 [EMAIL PROTECTED] wrote:
  Hi Igor,
 
 what? why would you ever load the whole dataset?
  just to avoid 2 calls on smallish datasets, especially when there are
  multiple joins and database isnt on the same box.

 so you think pushing all that extra data over the network is actually
 more efficient then doing another query wtf.

 yeah. because select count() queries are the most expensive queries
 you can run on the database. you are right, its totally going to kill
 it. you know how all those sites 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()?
 
  Ouch.
  I just want to limit calls if possible to the database as waiting for
 i/o's
  is never great for scalability. I'm not 'having a go' at wicket or
 DataViews
  or anything, just trying to understand it. I never claimed to be a guru -
  far from it.

 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?

 -igor

 
  Wayne
 
 
  On Wed, Nov 26, 2008 at 5:58 PM, Igor Vaynberg [EMAIL PROTECTED]
 wrote:
 
  On Wed, Nov 26, 2008 at 7:32 AM, Wayne Pope
  [EMAIL PROTECTED] wrote:
   I'm sure I must be missing something still, as I can't beleive that we
  need
   to either a) load the whole data set
 
  what? why would you ever load the whole dataset?
 
  b) call count on the Db , then load in
   the iterator mehod. Thats going to kill the database in prod (or
 really
  not
   help.)
 
  yeah. because select count() queries are the most expensive queries
  you can run on the database. you are right, its totally going to kill
  it. you know how all those sites 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]




Re: DateTimeField and java.util.Calendar

2008-11-26 Thread Eduardo Simioni
Nobody? Am I the only one having problems with these fields?

Thanks,

Eduardo.

On 11/25/08, Eduardo Simioni [EMAIL PROTECTED] wrote:

 Thanks for the hints.

 The conversion using nested models worked, although I have had to do some
 ugly things in the code because, unlike other fields, date fields model's
 don't get automatically updated when the form model is updated. Probably
 because of the converter model, it would definitely be better if we could
 work with something more magic. But for now that's ok.

 The problem now is that the date fields don't show up as expected in the
 page. I tried the DateTextField as in the examples but the button to open
 the calendar pop-up is not showing in the page.
 The DateTimeField (my first option) has a different problem, it shows an
 extra field that does nothing, I could not manage to remove it. Are these
 known bugs? I'm using 1.4-m3.

 See this image: http://www.simioni.net/wicket-date-fields-problems.jpg

 The relevant parts of the code for the class and page are the following:

 Class:
 private class RankingForm extends EntityFormRanking {

 private CalendarToDateModel modelStartDate;
 private CalendarToDateModel modelEndDate;

 public RankingForm( IModelRanking model, Component dataTable ) {
 super( model, dataTable );
 add( new TextFieldRanking( name ) );
 modelStartDate = new CalendarToDateModel( new
 PropertyModelCalendar( model, startDate ) );
 add( new DateTextField( startDate, modelStartDate, new
 StyleDateConverter( SM, false ) ) );
 modelEndDate = new CalendarToDateModel( new
 PropertyModelCalendar( model, endDate ) );
 add( new DateTimeField( endDate, modelEndDate ) );
 add( new TextFieldRanking( scoreRight ) );
 add( new TextFieldRanking( scoreWrong ) );
 add( new TextFieldRanking( scoreLimit ) );
 }

 @Override
 public MarkupContainer setDefaultModel( IModel? model ) {
 modelStartDate.setDefaultModel( new PropertyModelCalendar(
 model, startDate ) );
 modelEndDate.setDefaultModel( new PropertyModelCalendar(
 model, endDate ) );
 return super.setDefaultModel( model );
 }
 ...

 HTML:
 form wicket:id=form
 h2 wicket:id=createEditCriar/Editar Ranking/h2
 div id=feedbackPanel wicket:id=feedbackPanelFeedback
 Panel/div
 label for=nameNome/label: input wicket:id=name
 type=text size=20/br /
 label for=startDateData/Hora Início/label: input
 type=text wicket:id=startDate/br /
 label for=endDateData/Hora Fim/label: input type=text
 wicket:id=endDate/br /
 label for=scoreRightPontos para Acerto/label: input
 wicket:id=scoreRight type=text size=10/br /
 label for=scoreWrongPontos para Erro/label: input
 wicket:id=scoreWrong type=text size=10/br /
 label for=scoreLimitLimite de Pontos/label: input
 wicket:id=scoreLimit type=text size=10/br /
 ...


 Does anyone know a solution for these problems?

 Thanks!

 Eduardo.


 On 11/24/08, Jeremy Thomerson [EMAIL PROTECTED] wrote:

 Yes - this would be a perfect time for a nested model - write a generic
 model that implements IModelDate and takes an IModelCalendar as its
 input.

 See

 http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
 for
 assistance with the rest.


 --
 Jeremy Thomerson
 http://www.wickettraining.com




 On Mon, Nov 24, 2008 at 3:08 PM, Igor Vaynberg [EMAIL PROTECTED]
 wrote:


  write a model that converts to and from.
 
  -igor
 
  On Mon, Nov 24, 2008 at 12:30 PM, Eduardo Simioni
  [EMAIL PROTECTED] wrote:
   Hi all,
  
   I'm trying to use the DateTimeField from the wicket-datetime project.
 But
  I
   realized that it's stuck to java.util.Date, all my entities use
   java.util.Calendar to store dates. So the question is: Is there a
 clean
  way
   to work with DateTimeField and java.util.Calendar targets?
   I tried to find something in the list archive but looks like everybody
  uses
   java.util.Date, or I'm missing something silly.
  
   Thanks!
  
   Eduardo.*
   *
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 





Re: Using CompoundPropertyModel with FormComponentPanel

2008-11-26 Thread Igor Vaynberg
String.format(model.object.%s, id)));

On Wed, Nov 26, 2008 at 12:57 AM, Ned Collyer [EMAIL PROTECTED] wrote:

 I'm trying to throw together some components for easily creating accessible
 forms.

 I'm a fair bit along - just need some assistance with how to structure the
 class for use with CompoundPropertyModels.

 I want to be able to do the following:

 Form form = new Form(form, new CompoundPropertyModel(new User());
 form.add(new LabelledTextField(name))

 But I'm having difficulty setting the property model against the textfield
 inside my LabelledTextField.

 I can retrieve the values just fine, and they are set on the object from the
 forms CPM.

 I am using a fragment so that markup can be edited in a single place for all
 labelled form fields.  And different markup providers or variants can be
 used if any edge cases occur for any projects.

 The form fields can also used as easily as any other form fields in wicket -
 this is a different approach from wicketopia - which I've had a good dig
 through.

 I've gotta be close!


 /* the class itself */

 private final FormComponentLabel label;
 private final Label labelText;
 private final TextFieldT editor;
 private Fragment componentFragment;

 public class LabelledTextFieldT extends FormComponentPanelT {

public LabelledTextField(String id) {
super(id);

componentFragment = new Fragment(COMPONENT_ID, textField, this);
editor = new TextFieldT(editor, new PropertyModel(this,
 String.format(model.%s, id)));
label = new FormComponentLabel(label, editor);
labelText = new Label(labelText, TBA);
label.add(labelText);

componentFragment.add(editor);
componentFragment.add(label);

add(componentFragment);

setRenderBodyOnly(true);
}

protected void convertInput() {
setConvertedInput(editor.getConvertedInput());
}

public String getInput() {
return editor.getInput();
}
 }
 --
 View this message in context: 
 http://www.nabble.com/Using-CompoundPropertyModel-with-FormComponentPanel-tp20697019p20697019.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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



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



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

2008-11-26 Thread András Csáki
 The point is I'd rather avoid 2 calls where 1 will do. AbstractPageableView
 will do fine I believe.

You can do the counting and the actual query in one go, with something
like this if you happen to be  running on Oracle:

select
  data,
  count(data) over (order by rownum rows between unbounded preceding
and unbounded following ) cnt
from (
  select 1 data from dual
  union
  select 2 data from dual
)


Andras

-
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-26 Thread Igor Vaynberg
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 AM, Wayne Pope
 [EMAIL PROTECTED] wrote:
  Hi Igor,
 
 what? why would you ever load the whole dataset?
  just to avoid 2 calls on smallish datasets, especially when there are
  multiple joins and database isnt on the same box.

 so you think pushing all that extra data over the network is actually
 more efficient then doing another query wtf.

 yeah. because select count() queries are the most expensive queries
 you can run on the database. you are right, its totally going to kill
 it. you know how all those sites 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()?
 
  Ouch.
  I just want to limit calls if possible to the database as waiting for
 i/o's
  is never great for scalability. I'm not 'having a go' at wicket or
 DataViews
  or anything, just trying to understand it. I never claimed to be a guru -
  far from it.

 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?

 -igor

 
  Wayne
 
 
  On Wed, Nov 26, 2008 at 5:58 PM, Igor Vaynberg [EMAIL PROTECTED]
 wrote:
 
  On Wed, Nov 26, 2008 at 7:32 AM, Wayne Pope
  [EMAIL PROTECTED] wrote:
   I'm sure I must be missing something still, as I can't beleive that we
  need
   to either a) load the whole data set
 
  what? why would you ever load the whole dataset?
 
  b) call count on the Db , then load in
   the iterator mehod. Thats going to kill the database in prod (or
 really
  not
   help.)
 
  yeah. because select count() queries are the most expensive queries
  you can run on the database. you are right, its totally going to kill
  it. you know how all those sites 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.
  
  
   

Re: RES: Wicket Session grows too big real fast

2008-11-26 Thread Casper Bang
Session/state-fullness is the no. #1 concern for me about Wicket. If you 
like to keep an eye on certain object trees during runtime, as an 
alternative to external profiling (which I've always found cumbersome) 
you can use TopCoders memory usage component:

http://software.topcoder.com/catalog/c_component.jsp?comp=7220243ver=2

/Casper


Bruno Cesar Borges wrote:

Maybe would be a good idea if Wicket could report memory usage for 
non-Wicket_Components (and non-standard Java objects, like String and 
Collections) in memory. I don't know if this could ever be possible.

-Mensagem original-
De: Ladislav Thon [mailto:[EMAIL PROTECTED]
Enviada em: quarta-feira, 26 de novembro de 2008 14:21
Para: users@wicket.apache.org
Assunto: Re: Wicket Session grows too big real fast


Agree. I was almost shocked :-) by Martijn's e-mail about keeping references
between pages. I believed it is a standard practice to keep reference to
previous page for the purpose of cancelling, and of course do it all the
time. It seems very natural to me. O-oops.

LT

2008/11/26 Piller Sébastien [EMAIL PROTECTED]

  

I vote for such a document, too. I am now trying to reduce my session size
too, and if I could find some hints somewhere (ie, be extremly carefull
with anonymous subclasses, etc) it may be a big plus.

jhp a écrit :



Removing references pointing to previous pages solved a lot, very good
point.
Also making sure that individual domain objects don't get stored to
session
makes  a difference. I have still a lot of code to go through to make sure
that all unnecessary references don't get stored to session, but making a
few changes in the most important pages makes already a big difference.

I noticed that this is a problem that others have experienced too. I guess
it is pretty easy unintentionally stuff the session with domain objects
,and
if using modern day persistence framework, those domain objects can be
quite
large if they have collections etc.

I think there is a need for small document outlining the common pitfalls
and
remedies for them. I haven't seen such. Wicket reference of course tells
about LoadableDetachableModel, but this thread has info that I haven't
found
anywhere else. I might try compose such a document, if I just have the
time
and energy in the near future.

Thanks to Martijn, Johan and John for your responses!

BR,
Jukka


  

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




***
Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) 
acima identificado(s),
podendo conter informações e/ou documentos confidencias/privilegiados e seu sigilo é protegido por 
lei. Caso você tenha recebido por engano, por favor, informe o remetente e apague-a de seu sistema.
Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, cópia ou uso sem 
expressa autorização do remetente. Opiniões pessoais do remetente não refletem, necessariamente, 
o ponto de vista da CETIP, o qual é divulgado somente por pessoas autorizadas.



Warning: This message was sent for exclusive use of the addressees above identified, possibly 
containing information and or privileged/confidential documents whose content is protected by law. 
In case you have mistakenly received it, please notify the sender and delete it from your system. 
Be noticed that the law forbids the retention, dissemination, distribution, copy or use without 
express authorization from the sender. Personal opinions of the sender do not necessarily reflect 
CETIP's point of view, which is only divulged by authorized personnel.

***


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

  



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



Re: continueToOriginalDestination and POST

2008-11-26 Thread kan
A user has started to work with the form, then was distracted for 20
minutes, then he comes back and presses submit.
Is it difficult to store PageParameters too?

2008/11/26 Jeremy Thomerson [EMAIL PROTECTED]:
 They shouldn't be able to access the bookmarkable page with the form (or,
 access the page, but have the form hidden until signed-in).  For
 continueToOriginalDestination, IIRC, Wicket just stores the URL, so you
 can't go back to a POST.

 On Wed, Nov 26, 2008 at 10:27 AM, kan [EMAIL PROTECTED] wrote:

 I have a site which requires authentication. I've made it via
 @AuthorizeInstantiation.
 Works well. But if a bookmarkable page has a form with method POST,
 and user presses submit after timeout, it redirects him to SignIn
 screen. After successful login the site redirects back (usinig
 continueToOriginalDestination) to the page and happens not very good
 thing - method on form onSubmit is called but with no data on it,
 because POST is lost during that redirects. Is there any easy reliable
 solution of the problem?

 --
 WBR, kan.

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




 --
 Jeremy Thomerson
 http://www.wickettraining.com




-- 
WBR, kan.

-
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-26 Thread Wayne Pope
 the number of calls itself is meaningless, i dont comprehend why
 people have a hard time understanding this simple fact.


The point for me is :

something like
select count(*) from user user1 inner join company com1 on user1.company_id=
com1.id where com1.code='dht2'  - called in size()
followed by
select firstName,lastName from user user1 inner join company com1 on
user1.company_id=com1.id where com1.code='dht2' limit 10 offset 20 - called
in iterator


is going to cost more than just:
select firstName,lastName from user user1 inner join company com1 on
user1.company_id=com1.id where com1.code='dht2' limit 10 offset 20
which is all that is needed

hence avoiding 2 calls where 1 will do.


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

2008-11-26 Thread jWeekend

Wayne,

 
http://donteattoomuch.blogspot.com/2008/04/partial-ajax-update-capable-list-view.html
This  may be interesting too.

Regards - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk 



Wayne Pope-2 wrote:
 
 Thanks Matej,
 
 I just noticed org.apache.wicket.markup.repeater.AbstractPageableViewT
 which seems what I'm ofter - I'll have a look and both and get something
 working.
 
 
 On Wed, Nov 26, 2008 at 5:57 PM, Matej Knopp [EMAIL PROTECTED]
 wrote:
 
 You can just take AbstractPageableView, IDataSource and IGridSortState
 from the code. It should do exactly what you want and It shouldn't
 have any dependencies on the rest of grids.

 -Matej

 On Wed, Nov 26, 2008 at 5:39 PM, Wayne Pope
 [EMAIL PROTECTED] wrote:
  Hi Matej,
 
 The idea is always to load one row more than required on page which
 tells the grid if there will be a next page or not.
 
  Great idea. I looked at the code and I think I'll do my own (simplied
  version) of your refreashingpage. I believe thats what we really want
 here,
  as we don't care about telling the user the total amount of rows.
 
  Thanks everyone for your comments and help
  Wayne
 
  On Wed, Nov 26, 2008 at 5:21 PM, Matej Knopp [EMAIL PROTECTED]
 wrote:
 
  Hi Wayne,
 
  if you feel brave enough you can take a look at inmethod grid
  components (available in wicket stuff svn -
  http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff  in trunk
  and 1.3 branch). The grid contains AbstractPageableView that can
  perform paging without having to know the number of rows upfront.
 
  The idea is always to load one row more than required on page which
  tells the grid if there will be a next page or not.
 
  -Matej
 
  On Wed, Nov 26, 2008 at 5:15 PM, Wayne Pope
  [EMAIL PROTECTED] wrote:
   Hi James,
  
   its not killing anything at the moment, I just don't like the idea
 of
   hitting the database with due cause.
   However I thinking about this some more I believe perhaps I should
 not
  use
   DataViews full stop - but RefreshingView instead?. Essentially I
 have
 in
   several places a large data set. I'm only interested in displaying
 say
  the
   first 10 rows. Then the user can click on load next 10 and thus
 display
   the next 'page' of results. They then have a choice of loading the
 next
  10
   or the previous 10, etc. Perhaps DataView is not really suited to
 this
  type
   of behaviour? more used where you want to see the number of pages a
  search
   result finds for example? If we're at the edge condition that there
 are
   exactly 20 results, when asking for the next 10, we simply disply
 the
   message 'no more results'.
  
  
  We just issue a count(*) query first to get the count
   Yes so this will be called every time the page is rendered no unless
 you
   cache as you stated, but you run the risk changing dataset?
  
   thanks
   Wayne
  
   On Wed, Nov 26, 2008 at 5:05 PM, James Carman 
  [EMAIL PROTECTED]wrote:
  
   We just issue a count(*) query first to get the count.  Then, we
 use
   individual queries to get each page's data.  If you feel confident
  enough
   that the count won't change (or you don't really care if it does),
 you
  can
   cache the value returned from it the count query (I don't know how
 often
   that gets called, really).  If calling the queries to get the
 individual
   page's data is killing your database, then you're doing something
 wrong,
   IMHO.
  
   On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope 
   [EMAIL PROTECTED] wrote:
  
Hi,
   
thanks for the replies.
   
Micheal O/Hoover - I still don't see how this works as you don't
 have
  the
limit and offset (that is used in Iterator). How do you know how
 many
   rows
to load in your size() method?
   
Michael S - thanks for the link - it it appears I must completely
  rewrite
the whole pagable/provider code (not looked at the code) to get
 this
  to
work?
   
I'm sure I must be missing something still, as I can't beleive
 that
 we
   need
to either a) load the whole data set b) call count on the Db ,
 then
  load
   in
the iterator mehod. Thats going to kill the database in prod (or
  really
   not
help.)
   
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.

Wicket and CoC

2008-11-26 Thread Ricardo Mayerhofer

I started to use wicket some time ago, and I'm really enjoying it. Best
framework ever.
But I've some suggestions.
I think wicket could be better if it had less boiler plate code. This could
be reduced by using CoC.
Take the FeedBackPanel for example, you always have to add the component on
the web page, even if no special handling is requires (which is almost the
case). 
Wicket could have some reserved ids, so if I add a markup with id
feedbackPanel, a feedbackpanel component is automatically added to that
page.
Another example is SubmitLink component. No special handling required, but
for wicket sake the developer must add it on the java the page.
-- 
View this message in context: 
http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.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: continueToOriginalDestination and POST

2008-11-26 Thread Jeremy Thomerson
You could add a feature request (and a patch?).

My point was don't let them start on the form until they are signed in if
being signed in is required for submitting the form.  This just makes sense.

Or, if what you're saying is that they are timing out while working on the
form, add an ajax update behavior that will keep them signed in / session
current.

On Wed, Nov 26, 2008 at 12:36 PM, kan [EMAIL PROTECTED] wrote:

 A user has started to work with the form, then was distracted for 20
 minutes, then he comes back and presses submit.
 Is it difficult to store PageParameters too?

 2008/11/26 Jeremy Thomerson [EMAIL PROTECTED]:
   They shouldn't be able to access the bookmarkable page with the form
 (or,
  access the page, but have the form hidden until signed-in).  For
  continueToOriginalDestination, IIRC, Wicket just stores the URL, so you
  can't go back to a POST.
 
  On Wed, Nov 26, 2008 at 10:27 AM, kan [EMAIL PROTECTED] wrote:
 
  I have a site which requires authentication. I've made it via
  @AuthorizeInstantiation.
  Works well. But if a bookmarkable page has a form with method POST,
  and user presses submit after timeout, it redirects him to SignIn
  screen. After successful login the site redirects back (usinig
  continueToOriginalDestination) to the page and happens not very good
  thing - method on form onSubmit is called but with no data on it,
  because POST is lost during that redirects. Is there any easy reliable
  solution of the problem?
 
  --
  WBR, kan.
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
  --
  Jeremy Thomerson
  http://www.wickettraining.com
 



 --
  WBR, kan.

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




-- 
Jeremy Thomerson
http://www.wickettraining.com


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

2008-11-26 Thread Jeremy Thomerson
But the second call is much longer and has a much different point.  If you
must display the total rows, you need to do the first call anyway.  If you
don't, then use a different component and avoid the first call, only getting
the necessary rows, perhaps plus one to see if there is another page
needed (ala inmethod).

A count call will be very quick.  And it transfers minimal data.

On Wed, Nov 26, 2008 at 12:45 PM, Wayne Pope 
[EMAIL PROTECTED] wrote:

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

 The point for me is :

 something like
 select count(*) from user user1 inner join company com1 on
 user1.company_id=
 com1.id where com1.code='dht2'  - called in size()
 followed by
 select firstName,lastName from user user1 inner join company com1 on
 user1.company_id=com1.id where com1.code='dht2' limit 10 offset 20 -
 called
 in iterator


 is going to cost more than just:
 select firstName,lastName from user user1 inner join company com1 on
 user1.company_id=com1.id where com1.code='dht2' limit 10 offset 20
 which is all that is needed

 hence avoiding 2 calls where 1 will do.




-- 
Jeremy Thomerson
http://www.wickettraining.com


Re: Wicket and CoC

2008-11-26 Thread Martijn Dashorst
-1000,000,000,000

First please don't assume someone understands your acronym du jour. I
had to think really hard to understand that CoC means convention over
configuration instead of the Dutch meaning gay rights group.

Second this is not a task for wicket. You can  think up any CoCamania
you want in your own addon framework and publish it on 'stuff or
google code, but I won't be using it ever nor including it in core.

The biggest plus point of wicket is that it doesn't perform magic. I
don't need nor want to have to wave a dead chicken in front of my
monitor and spend the bigger part of the day wondering which
incantation I did wrong.

Martijn
On 11/26/08, Ricardo Mayerhofer [EMAIL PROTECTED] wrote:

 I started to use wicket some time ago, and I'm really enjoying it. Best
 framework ever.
 But I've some suggestions.
 I think wicket could be better if it had less boiler plate code. This could
 be reduced by using CoC.
 Take the FeedBackPanel for example, you always have to add the component on
 the web page, even if no special handling is requires (which is almost the
 case).
 Wicket could have some reserved ids, so if I add a markup with id
 feedbackPanel, a feedbackpanel component is automatically added to that
 page.
 Another example is SubmitLink component. No special handling required, but
 for wicket sake the developer must add it on the java the page.
 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.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]




-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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



Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

2008-11-26 Thread Ryan McKinley


On Nov 26, 2008, at 11:38 AM, Jeremy Thomerson wrote:

I think Wayne was referring not to your post, but in general - if we  
package
most of the projects up neatly under one parent, then other projects  
that

aren't in the same subdirectory / build cycle may get lost.


Hopefully having a cleaned up source tree with better pom/version  
reuse will make it much easier to keep things up-to-date and useful.   
It should not be that hard to clean up most of the existing projects.


Another thing that would be nice to add to the parent pom is:
http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html

I have found it invaluable to have the SVN version cooked into the  
artifacts -- particularly after something has been running stable for  
a year and you can't possibly remember exactly where it came from.


ryan




--
Jeremy Thomerson
http://www.wickettraining.com


On Wed, Nov 26, 2008 at 7:10 AM, James Carman [EMAIL PROTECTED] 
wrote:


Merely bundling the examples with the code itself shouldn't cause  
this,

do
you think?

On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope 
[EMAIL PROTECTED] wrote:


YES.
However I feel people may pass over the earlier branches  
(especially when
we're on Wicket version 5.8!) and hence miss some great code that  
may not

take much to get working and maintain on the newer branch.

On Wed, Nov 26, 2008 at 2:06 AM, James Carman 

[EMAIL PROTECTED]

wrote:


Yes, our entire project at work is like this.  The top-level  
project

holds multiple modules.  Each has a common, server, and client
submodule.  Works like a charm.

On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
Great idea!  Yes.  I have not nested any projects three deep in  
the

past,

but it should work.  Has anybody else tried this?

It would be:

wicket-stuff-parent
-- wicket-foo
   -- wicket-foo-core
   -- wicket-foo-examples

On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED]

wrote:


I don't know if this has already been discussed, but another  
part of

the

cleanup that would be nice is to group the main project and the

example

project into a folder with a common parent pom.

For example, I find the layout of:







https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/


much easier to use/maintain then the apparent standard of
/wicketstuff-project  /wicketstuff-project-example







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/


one key thing about this change is that mvn eclipse:eclipse makes

the

example project depend on the core project

perhaps this could be added to the 'organize' task?

ryan





-

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





--
Jeremy Thomerson
http://www.wickettraining.com



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









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



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

2008-11-26 Thread Wayne Pope
If you must display the total rows,
which I don't

then use a different component and avoid the first call
Which is what i said in my 3rd post.


On Wed, Nov 26, 2008 at 7:51 PM, Jeremy Thomerson [EMAIL PROTECTED]
 wrote:

 But the second call is much longer and has a much different point.  If you
 must display the total rows, you need to do the first call anyway.  If you
 don't, then use a different component and avoid the first call, only
 getting
 the necessary rows, perhaps plus one to see if there is another page
 needed (ala inmethod).

 A count call will be very quick.  And it transfers minimal data.

 On Wed, Nov 26, 2008 at 12:45 PM, Wayne Pope 
 [EMAIL PROTECTED] wrote:

   the number of calls itself is meaningless, i dont comprehend why
   people have a hard time understanding this simple fact.
  
 
  The point for me is :
 
  something like
  select count(*) from user user1 inner join company com1 on
  user1.company_id=
  com1.id where com1.code='dht2'  - called in size()
  followed by
  select firstName,lastName from user user1 inner join company com1 on
  user1.company_id=com1.id where com1.code='dht2' limit 10 offset 20 -
  called
  in iterator
 
 
  is going to cost more than just:
  select firstName,lastName from user user1 inner join company com1 on
  user1.company_id=com1.id where com1.code='dht2' limit 10 offset 20
  which is all that is needed
 
  hence avoiding 2 calls where 1 will do.
 



 --
 Jeremy Thomerson
 http://www.wickettraining.com



Re: Wicket and CoC

2008-11-26 Thread Sven Meier

With IComponentResolver you can easily roll your own 'CoC' solution.

Sven

Ricardo Mayerhofer schrieb:

I started to use wicket some time ago, and I'm really enjoying it. Best
framework ever.
But I've some suggestions.
I think wicket could be better if it had less boiler plate code. This could
be reduced by using CoC.
Take the FeedBackPanel for example, you always have to add the component on
the web page, even if no special handling is requires (which is almost the
case). 
Wicket could have some reserved ids, so if I add a markup with id

feedbackPanel, a feedbackpanel component is automatically added to that
page.
Another example is SubmitLink component. No special handling required, but
for wicket sake the developer must add it on the java the page.
  



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



Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

2008-11-26 Thread Jeremy Thomerson
Good suggestion - I like that, too.  I'll plan on adding it to the parent
POM.

Thanks!

On Wed, Nov 26, 2008 at 1:13 PM, Ryan McKinley [EMAIL PROTECTED] wrote:


 On Nov 26, 2008, at 11:38 AM, Jeremy Thomerson wrote:

 I think Wayne was referring not to your post, but in general - if we
 package
 most of the projects up neatly under one parent, then other projects that
 aren't in the same subdirectory / build cycle may get lost.


 Hopefully having a cleaned up source tree with better pom/version reuse
 will make it much easier to keep things up-to-date and useful.  It should
 not be that hard to clean up most of the existing projects.

 Another thing that would be nice to add to the parent pom is:

 http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html

 I have found it invaluable to have the SVN version cooked into the
 artifacts -- particularly after something has been running stable for a year
 and you can't possibly remember exactly where it came from.

 ryan




 --
 Jeremy Thomerson
 http://www.wickettraining.com


 On Wed, Nov 26, 2008 at 7:10 AM, James Carman [EMAIL PROTECTED]
 wrote:

 Merely bundling the examples with the code itself shouldn't cause this,
 do
 you think?

 On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope 
 [EMAIL PROTECTED] wrote:

 YES.
 However I feel people may pass over the earlier branches (especially
 when
 we're on Wicket version 5.8!) and hence miss some great code that may
 not
 take much to get working and maintain on the newer branch.

 On Wed, Nov 26, 2008 at 2:06 AM, James Carman 

 [EMAIL PROTECTED]

 wrote:


 Yes, our entire project at work is like this.  The top-level project
 holds multiple modules.  Each has a common, server, and client
 submodule.  Works like a charm.

 On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson
 [EMAIL PROTECTED] wrote:

 Great idea!  Yes.  I have not nested any projects three deep in the

 past,

 but it should work.  Has anybody else tried this?

 It would be:

 wicket-stuff-parent
 -- wicket-foo
   -- wicket-foo-core
   -- wicket-foo-examples

 On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED]

 wrote:


 I don't know if this has already been discussed, but another part of

 the

  cleanup that would be nice is to group the main project and the

 example

  project into a folder with a common parent pom.

 For example, I find the layout of:





 https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/


 much easier to use/maintain then the apparent standard of
 /wicketstuff-project  /wicketstuff-project-example





 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/


 one key thing about this change is that mvn eclipse:eclipse makes

 the

  example project depend on the core project

 perhaps this could be added to the 'organize' task?

 ryan




 -

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




 --
 Jeremy Thomerson
 http://www.wickettraining.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]




-- 
Jeremy Thomerson
http://www.wickettraining.com


Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

2008-11-26 Thread James Carman
The revision doesn't tell you everything, though.  Typically, you don't
release from trunk (at least you're not supposed to).  You create a tag
and create the release from there.  So, the tag/revision would be what you
need to easily recreate the release.

On Wed, Nov 26, 2008 at 2:13 PM, Ryan McKinley [EMAIL PROTECTED] wrote:


 On Nov 26, 2008, at 11:38 AM, Jeremy Thomerson wrote:

  I think Wayne was referring not to your post, but in general - if we
 package
 most of the projects up neatly under one parent, then other projects that
 aren't in the same subdirectory / build cycle may get lost.


 Hopefully having a cleaned up source tree with better pom/version reuse
 will make it much easier to keep things up-to-date and useful.  It should
 not be that hard to clean up most of the existing projects.

 Another thing that would be nice to add to the parent pom is:

 http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html

 I have found it invaluable to have the SVN version cooked into the
 artifacts -- particularly after something has been running stable for a year
 and you can't possibly remember exactly where it came from.

 ryan




 --
 Jeremy Thomerson
 http://www.wickettraining.com


 On Wed, Nov 26, 2008 at 7:10 AM, James Carman [EMAIL PROTECTED]
 wrote:

  Merely bundling the examples with the code itself shouldn't cause this,
 do
 you think?

 On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope 
 [EMAIL PROTECTED] wrote:

  YES.
 However I feel people may pass over the earlier branches (especially
 when
 we're on Wicket version 5.8!) and hence miss some great code that may
 not
 take much to get working and maintain on the newer branch.

 On Wed, Nov 26, 2008 at 2:06 AM, James Carman 

 [EMAIL PROTECTED]

 wrote:


  Yes, our entire project at work is like this.  The top-level project
 holds multiple modules.  Each has a common, server, and client
 submodule.  Works like a charm.

 On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson
 [EMAIL PROTECTED] wrote:

 Great idea!  Yes.  I have not nested any projects three deep in the

 past,

 but it should work.  Has anybody else tried this?

 It would be:

 wicket-stuff-parent
 -- wicket-foo
   -- wicket-foo-core
   -- wicket-foo-examples

 On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED]

 wrote:


  I don't know if this has already been discussed, but another part of

 the

 cleanup that would be nice is to group the main project and the

 example

 project into a folder with a common parent pom.

 For example, I find the layout of:





 https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/


 much easier to use/maintain then the apparent standard of
 /wicketstuff-project  /wicketstuff-project-example





 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/


 one key thing about this change is that mvn eclipse:eclipse makes

 the

 example project depend on the core project

 perhaps this could be added to the 'organize' task?

 ryan




 -

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




 --
 Jeremy Thomerson
 http://www.wickettraining.com


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






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




Re: Wicket and CoC

2008-11-26 Thread Ricardo Mayerhofer

Thanks Sven! I will look into it.


svenmeier wrote:
 
 With IComponentResolver you can easily roll your own 'CoC' solution.
 
 Sven
 
 Ricardo Mayerhofer schrieb:
 I started to use wicket some time ago, and I'm really enjoying it. Best
 framework ever.
 But I've some suggestions.
 I think wicket could be better if it had less boiler plate code. This
 could
 be reduced by using CoC.
 Take the FeedBackPanel for example, you always have to add the component
 on
 the web page, even if no special handling is requires (which is almost
 the
 case). 
 Wicket could have some reserved ids, so if I add a markup with id
 feedbackPanel, a feedbackpanel component is automatically added to that
 page.
 Another example is SubmitLink component. No special handling required,
 but
 for wicket sake the developer must add it on the java the page.
   
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Wicket-and-CoC-tp20706881p20708568.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: Wicket and CoC

2008-11-26 Thread Ricardo Mayerhofer

Hi Martijin,
First of all thank you for your response.
I guess automation != magic. Automation means that computers or frameworks
helps humans accomplishing repetitive tasks, so developers can better focus
on the problem being solved, rather than having to copy and paste same code
over and over (boilerplate).
If one add a markup named feedbackPanel, what is he intent, to make a combo
box? Or he have to tell it again, in a different way? IMO it's better to
tell one time what I'm willing to do rather than 2, 3, 5...


Martijn Dashorst wrote:
 
 -1000,000,000,000
 
 First please don't assume someone understands your acronym du jour. I
 had to think really hard to understand that CoC means convention over
 configuration instead of the Dutch meaning gay rights group.
 
 Second this is not a task for wicket. You can  think up any CoCamania
 you want in your own addon framework and publish it on 'stuff or
 google code, but I won't be using it ever nor including it in core.
 
 The biggest plus point of wicket is that it doesn't perform magic. I
 don't need nor want to have to wave a dead chicken in front of my
 monitor and spend the bigger part of the day wondering which
 incantation I did wrong.
 
 Martijn
 On 11/26/08, Ricardo Mayerhofer [EMAIL PROTECTED] wrote:

 I started to use wicket some time ago, and I'm really enjoying it. Best
 framework ever.
 But I've some suggestions.
 I think wicket could be better if it had less boiler plate code. This
 could
 be reduced by using CoC.
 Take the FeedBackPanel for example, you always have to add the component
 on
 the web page, even if no special handling is requires (which is almost
 the
 case).
 Wicket could have some reserved ids, so if I add a markup with id
 feedbackPanel, a feedbackpanel component is automatically added to that
 page.
 Another example is SubmitLink component. No special handling required,
 but
 for wicket sake the developer must add it on the java the page.
 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.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]


 
 
 -- 
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.4 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.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: Wicket and CoC

2008-11-26 Thread Jeremy Thomerson
You can also add it to your base page and include it in any page you want,
or include it in your base page layout - now it's automatically on every
page.  In other words, everyone may want to do something a different way, so
there's no reason the framework should do it automatically your way - but it
should make it easy for you to do it yourself - which it does.

On Wed, Nov 26, 2008 at 2:51 PM, Ricardo Mayerhofer 
[EMAIL PROTECTED] wrote:


 Hi Martijin,
 First of all thank you for your response.
 I guess automation != magic. Automation means that computers or frameworks
 helps humans accomplishing repetitive tasks, so developers can better focus
 on the problem being solved, rather than having to copy and paste same code
 over and over (boilerplate).
 If one add a markup named feedbackPanel, what is he intent, to make a combo
 box? Or he have to tell it again, in a different way? IMO it's better to
 tell one time what I'm willing to do rather than 2, 3, 5...


 Martijn Dashorst wrote:
 
  -1000,000,000,000
 
  First please don't assume someone understands your acronym du jour. I
  had to think really hard to understand that CoC means convention over
  configuration instead of the Dutch meaning gay rights group.
 
  Second this is not a task for wicket. You can  think up any CoCamania
  you want in your own addon framework and publish it on 'stuff or
  google code, but I won't be using it ever nor including it in core.
 
  The biggest plus point of wicket is that it doesn't perform magic. I
  don't need nor want to have to wave a dead chicken in front of my
  monitor and spend the bigger part of the day wondering which
  incantation I did wrong.
 
  Martijn
  On 11/26/08, Ricardo Mayerhofer [EMAIL PROTECTED] wrote:
 
  I started to use wicket some time ago, and I'm really enjoying it. Best
  framework ever.
  But I've some suggestions.
  I think wicket could be better if it had less boiler plate code. This
  could
  be reduced by using CoC.
  Take the FeedBackPanel for example, you always have to add the component
  on
  the web page, even if no special handling is requires (which is almost
  the
  case).
  Wicket could have some reserved ids, so if I add a markup with id
  feedbackPanel, a feedbackpanel component is automatically added to that
  page.
  Another example is SubmitLink component. No special handling required,
  but
  for wicket sake the developer must add it on the java the page.
  --
  View this message in context:
  http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.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]
 
 
 
 
  --
  Become a Wicket expert, learn from the best: http://wicketinaction.com
  Apache Wicket 1.3.4 is released
  Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.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]




-- 
Jeremy Thomerson
http://www.wickettraining.com


Re: Wicket and CoC

2008-11-26 Thread Igor Vaynberg
in our app components with id feedbackPanel are often used to present
a user with a user-feedback panel they can use to submit
suggestions...

-igor

On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
[EMAIL PROTECTED] wrote:

 Hi Martijin,
 First of all thank you for your response.
 I guess automation != magic. Automation means that computers or frameworks
 helps humans accomplishing repetitive tasks, so developers can better focus
 on the problem being solved, rather than having to copy and paste same code
 over and over (boilerplate).
 If one add a markup named feedbackPanel, what is he intent, to make a combo
 box? Or he have to tell it again, in a different way? IMO it's better to
 tell one time what I'm willing to do rather than 2, 3, 5...


 Martijn Dashorst wrote:

 -1000,000,000,000

 First please don't assume someone understands your acronym du jour. I
 had to think really hard to understand that CoC means convention over
 configuration instead of the Dutch meaning gay rights group.

 Second this is not a task for wicket. You can  think up any CoCamania
 you want in your own addon framework and publish it on 'stuff or
 google code, but I won't be using it ever nor including it in core.

 The biggest plus point of wicket is that it doesn't perform magic. I
 don't need nor want to have to wave a dead chicken in front of my
 monitor and spend the bigger part of the day wondering which
 incantation I did wrong.

 Martijn
 On 11/26/08, Ricardo Mayerhofer [EMAIL PROTECTED] wrote:

 I started to use wicket some time ago, and I'm really enjoying it. Best
 framework ever.
 But I've some suggestions.
 I think wicket could be better if it had less boiler plate code. This
 could
 be reduced by using CoC.
 Take the FeedBackPanel for example, you always have to add the component
 on
 the web page, even if no special handling is requires (which is almost
 the
 case).
 Wicket could have some reserved ids, so if I add a markup with id
 feedbackPanel, a feedbackpanel component is automatically added to that
 page.
 Another example is SubmitLink component. No special handling required,
 but
 for wicket sake the developer must add it on the java the page.
 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.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]




 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.4 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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




 --
 View this message in context: 
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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



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



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

2008-11-26 Thread rgoodwin

Still is being disputed unfortunately :(

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

For those who believe in the 1-query approach, ergo the DTO pattern, writing
an alternative to the Wicket data provision using a DTO approach isn't a
terrible hardship ... just annoying to be sprung with on day one of using
Wicket. But pain is experienced later when encountering the Wicket data
provision and paging mechanism coupling. The paging mechanism is far less
joy to replace ...

IReallyHateDataProvider



Hoover, William wrote:
 
 I think the idea behind this is that size will be called first. If the
 size is zero there is no need to proceed with the call to get the items.
 I don't necessarily agree with this approach because a lot of service
 calls can capture the data in one call (even down to the database level-
 some support getting the size/results in one call), but the last time I
 brought this issue up it was disputed.
 

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



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

2008-11-26 Thread Bruno Cesar Borges
Here's what I've commented on this issue:

I think the purpose of Transfer Object Pattern , where it says it wants to 
reduce remote calls between tiers over the network is related to tiers like 
client / server architectures.

This means that:

i) A Swing client requests a query on a table for a remote EJB
ii) The EJB executes two calls on the database
ii.a) select count(*)
ii.b) select * ... limit x offset y / rownum between z and k // whatever DB 
paging technique is being used.
iii) Put all this information into one single Transfer Object
iv) Send the object back to the client application over the network

So, if your Web Application is running on the same server with your services 
(EJBs, Spring Services, whatever), this means that you are not going to 
transport data over the network between those tiers (Web and Model). And there 
will be an implicit Transfer Object to the real client (web browser).

Following this logic: -1 for this improvement.

Regards,
Bruno

-Mensagem original-
De: rgoodwin [mailto:[EMAIL PROTECTED]
Enviada em: quarta-feira, 26 de novembro de 2008 19:01
Para: users@wicket.apache.org
Assunto: RE: Is there any other way? DataProviders must hit the Db twice
for (possible) large datasets



Still is being disputed unfortunately :(

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

For those who believe in the 1-query approach, ergo the DTO pattern, writing
an alternative to the Wicket data provision using a DTO approach isn't a
terrible hardship ... just annoying to be sprung with on day one of using
Wicket. But pain is experienced later when encountering the Wicket data
provision and paging mechanism coupling. The paging mechanism is far less
joy to replace ...

IReallyHateDataProvider



Hoover, William wrote:
 
 I think the idea behind this is that size will be called first. If the
 size is zero there is no need to proceed with the call to get the items.
 I don't necessarily agree with this approach because a lot of service
 calls can capture the data in one call (even down to the database level-
 some support getting the size/results in one call), but the last time I
 brought this issue up it was disputed.
 

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

***
Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) 
acima identificado(s),
podendo conter informações e/ou documentos confidencias/privilegiados e seu 
sigilo é protegido por 
lei. Caso você tenha recebido por engano, por favor, informe o remetente e 
apague-a de seu sistema.
Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, 
cópia ou uso sem 
expressa autorização do remetente. Opiniões pessoais do remetente não refletem, 
necessariamente, 
o ponto de vista da CETIP, o qual é divulgado somente por pessoas autorizadas.


Warning: This message was sent for exclusive use of the addressees above 
identified, possibly 
containing information and or privileged/confidential documents whose content 
is protected by law. 
In case you have mistakenly received it, please notify the sender and delete it 
from your system. 
Be noticed that the law forbids the retention, dissemination, distribution, 
copy or use without 
express authorization from the sender. Personal opinions of the sender do not 
necessarily reflect 
CETIP's point of view, which is only divulged by authorized personnel.
***


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



Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

2008-11-26 Thread Ryan McKinley
Right, the svn url is important especially when you deploy from 'non- 
released' versions (like most of wicketstuff)


This is what I have in my pom.xml


plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-jar-plugin/artifactId
  configuration
archive
  manifestEntries
  Specification-Title${project.name}/Specification- 
Title
  Specification-Version${project.version}/ 
Specification-Version
  Implementation-Title${project.name}/Implementation- 
Title
  Implementation-Version${project.version} $ 
{buildNumber} - ${user.name}/Implementation-Version

  SCM-Revision${buildNumber}/SCM-Revision
  SCM-url${scm.url}/SCM-url
  /manifestEntries
/archive
  /configuration
/plugin


On Nov 26, 2008, at 3:24 PM, James Carman wrote:

The revision doesn't tell you everything, though.  Typically, you  
don't
release from trunk (at least you're not supposed to).  You create  
a tag
and create the release from there.  So, the tag/revision would be  
what you

need to easily recreate the release.

On Wed, Nov 26, 2008 at 2:13 PM, Ryan McKinley [EMAIL PROTECTED]  
wrote:




On Nov 26, 2008, at 11:38 AM, Jeremy Thomerson wrote:

I think Wayne was referring not to your post, but in general - if we

package
most of the projects up neatly under one parent, then other  
projects that

aren't in the same subdirectory / build cycle may get lost.



Hopefully having a cleaned up source tree with better pom/version  
reuse
will make it much easier to keep things up-to-date and useful.  It  
should

not be that hard to clean up most of the existing projects.

Another thing that would be nice to add to the parent pom is:

http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html

I have found it invaluable to have the SVN version cooked into the
artifacts -- particularly after something has been running stable  
for a year

and you can't possibly remember exactly where it came from.

ryan





--
Jeremy Thomerson
http://www.wickettraining.com


On Wed, Nov 26, 2008 at 7:10 AM, James Carman [EMAIL PROTECTED]

wrote:


Merely bundling the examples with the code itself shouldn't  
cause this,

do
you think?

On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope 
[EMAIL PROTECTED] wrote:

YES.
However I feel people may pass over the earlier branches  
(especially

when
we're on Wicket version 5.8!) and hence miss some great code  
that may

not
take much to get working and maintain on the newer branch.

On Wed, Nov 26, 2008 at 2:06 AM, James Carman 


[EMAIL PROTECTED]


wrote:




Yes, our entire project at work is like this.  The top-level  
project

holds multiple modules.  Each has a common, server, and client
submodule.  Works like a charm.

On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:

Great idea!  Yes.  I have not nested any projects three deep  
in the



past,



but it should work.  Has anybody else tried this?


It would be:

wicket-stuff-parent
-- wicket-foo
 -- wicket-foo-core
 -- wicket-foo-examples

On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED] 




wrote:



I don't know if this has already been discussed, but another  
part of



the



cleanup that would be nice is to group the main project and the



example



project into a folder with a common parent pom.


For example, I find the layout of:








https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/




much easier to use/maintain then the apparent standard of
/wicketstuff-project  /wicketstuff-project-example








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/



one key thing about this change is that mvn eclipse:eclipse  
makes



the



example project depend on the core project


perhaps this could be added to the 'organize' task?

ryan




-



To unsubscribe, e-mail: [EMAIL PROTECTED]

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





--
Jeremy Thomerson
http://www.wickettraining.com



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









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





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



Re: Wicket and CoC

2008-11-26 Thread Ricardo Mayerhofer

Perhaps the name could be userFeedBackPanel :) 
One Word per Concept (Clean Code, Bob Martin, p. 26)

I'm just talking about code duplication, add( new SubmitLink( submitLink )
) and similars many times in a code doenst makes a programmer happier.
OOP (object oriented programming) isn't always the best tools to solve code
duplication. So sometimes AOP (aspect oriented programming) comes to mind,
other times CoC (convention over configuration). (I hope Martijn is happy by
the acronyms explanations :)).

I'm not saying that it should be in wicket core (as you guys keep it thin as
you can) and I'm glad wicket core makes me able to extend it, in a way I can
implement this (thats a huge plus)

I'm just saying that this is not a bad idea, mainly when you care about
saving programming efforts and clean code. 


igor.vaynberg wrote:
 
 in our app components with id feedbackPanel are often used to present
 a user with a user-feedback panel they can use to submit
 suggestions...
 
 -igor
 
 On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
 [EMAIL PROTECTED] wrote:

 Hi Martijin,
 First of all thank you for your response.
 I guess automation != magic. Automation means that computers or
 frameworks
 helps humans accomplishing repetitive tasks, so developers can better
 focus
 on the problem being solved, rather than having to copy and paste same
 code
 over and over (boilerplate).
 If one add a markup named feedbackPanel, what is he intent, to make a
 combo
 box? Or he have to tell it again, in a different way? IMO it's better to
 tell one time what I'm willing to do rather than 2, 3, 5...


 Martijn Dashorst wrote:

 -1000,000,000,000

 First please don't assume someone understands your acronym du jour. I
 had to think really hard to understand that CoC means convention over
 configuration instead of the Dutch meaning gay rights group.

 Second this is not a task for wicket. You can  think up any CoCamania
 you want in your own addon framework and publish it on 'stuff or
 google code, but I won't be using it ever nor including it in core.

 The biggest plus point of wicket is that it doesn't perform magic. I
 don't need nor want to have to wave a dead chicken in front of my
 monitor and spend the bigger part of the day wondering which
 incantation I did wrong.

 Martijn
 On 11/26/08, Ricardo Mayerhofer [EMAIL PROTECTED] wrote:

 I started to use wicket some time ago, and I'm really enjoying it. Best
 framework ever.
 But I've some suggestions.
 I think wicket could be better if it had less boiler plate code. This
 could
 be reduced by using CoC.
 Take the FeedBackPanel for example, you always have to add the
 component
 on
 the web page, even if no special handling is requires (which is almost
 the
 case).
 Wicket could have some reserved ids, so if I add a markup with id
 feedbackPanel, a feedbackpanel component is automatically added to that
 page.
 Another example is SubmitLink component. No special handling required,
 but
 for wicket sake the developer must add it on the java the page.
 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.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]




 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.4 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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




 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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


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

-- 
View this message in context: 
http://www.nabble.com/Wicket-and-CoC-tp20706881p20709706.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]



RES: Wicket and CoC

2008-11-26 Thread Bruno Cesar Borges
There you go. What about creating a project into Wicket Stuff, called ... 
WiCooCo?

Wicket Conventioned over Configurations =)



-Mensagem original-
De: Ricardo Mayerhofer [mailto:[EMAIL PROTECTED]
Enviada em: quarta-feira, 26 de novembro de 2008 19:57
Para: users@wicket.apache.org
Assunto: Re: Wicket and CoC



Perhaps the name could be userFeedBackPanel :) 
One Word per Concept (Clean Code, Bob Martin, p. 26)

I'm just talking about code duplication, add( new SubmitLink( submitLink )
) and similars many times in a code doenst makes a programmer happier.
OOP (object oriented programming) isn't always the best tools to solve code
duplication. So sometimes AOP (aspect oriented programming) comes to mind,
other times CoC (convention over configuration). (I hope Martijn is happy by
the acronyms explanations :)).

I'm not saying that it should be in wicket core (as you guys keep it thin as
you can) and I'm glad wicket core makes me able to extend it, in a way I can
implement this (thats a huge plus)

I'm just saying that this is not a bad idea, mainly when you care about
saving programming efforts and clean code. 


igor.vaynberg wrote:
 
 in our app components with id feedbackPanel are often used to present
 a user with a user-feedback panel they can use to submit
 suggestions...
 
 -igor
 
 On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
 [EMAIL PROTECTED] wrote:

 Hi Martijin,
 First of all thank you for your response.
 I guess automation != magic. Automation means that computers or
 frameworks
 helps humans accomplishing repetitive tasks, so developers can better
 focus
 on the problem being solved, rather than having to copy and paste same
 code
 over and over (boilerplate).
 If one add a markup named feedbackPanel, what is he intent, to make a
 combo
 box? Or he have to tell it again, in a different way? IMO it's better to
 tell one time what I'm willing to do rather than 2, 3, 5...


 Martijn Dashorst wrote:

 -1000,000,000,000

 First please don't assume someone understands your acronym du jour. I
 had to think really hard to understand that CoC means convention over
 configuration instead of the Dutch meaning gay rights group.

 Second this is not a task for wicket. You can  think up any CoCamania
 you want in your own addon framework and publish it on 'stuff or
 google code, but I won't be using it ever nor including it in core.

 The biggest plus point of wicket is that it doesn't perform magic. I
 don't need nor want to have to wave a dead chicken in front of my
 monitor and spend the bigger part of the day wondering which
 incantation I did wrong.

 Martijn
 On 11/26/08, Ricardo Mayerhofer [EMAIL PROTECTED] wrote:

 I started to use wicket some time ago, and I'm really enjoying it. Best
 framework ever.
 But I've some suggestions.
 I think wicket could be better if it had less boiler plate code. This
 could
 be reduced by using CoC.
 Take the FeedBackPanel for example, you always have to add the
 component
 on
 the web page, even if no special handling is requires (which is almost
 the
 case).
 Wicket could have some reserved ids, so if I add a markup with id
 feedbackPanel, a feedbackpanel component is automatically added to that
 page.
 Another example is SubmitLink component. No special handling required,
 but
 for wicket sake the developer must add it on the java the page.
 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.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]




 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.4 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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




 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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


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

-- 
View this message in context: 
http://www.nabble.com/Wicket-and-CoC-tp20706881p20709706.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]

***
Atenção: Esta mensagem 

Re: Wicket and CoC

2008-11-26 Thread Igor Vaynberg
On Wed, Nov 26, 2008 at 1:57 PM, Ricardo Mayerhofer
[EMAIL PROTECTED] wrote:

 Perhaps the name could be userFeedBackPanel :)
 One Word per Concept (Clean Code, Bob Martin, p. 26)

why should conventions of a framework we use dictate our names in the
application domain? within our application user feedback is a well
known term. so just because we are using wicket we should change it?
this is why stuff like that doesnt go into core :)

 I'm just talking about code duplication, add( new SubmitLink( submitLink )
 ) and similars many times in a code doenst makes a programmer happier.
 OOP (object oriented programming) isn't always the best tools to solve code
 duplication. So sometimes AOP (aspect oriented programming) comes to mind,
 other times CoC (convention over configuration). (I hope Martijn is happy by
 the acronyms explanations :)).

 I'm not saying that it should be in wicket core (as you guys keep it thin as
 you can) and I'm glad wicket core makes me able to extend it, in a way I can
 implement this (thats a huge plus)

this kind of stuff adds ambiguity - that is mostly why it doesnt make
it into core. you say submitLink creates a component, fine, but in
our app we have our own subclass of SubmitLink we use that includes
our css styles, indicators, etc - which again breaks with your
suggestion.

 I'm just saying that this is not a bad idea, mainly when you care about
 saving programming efforts and clean code.

you are saving a few lines of code by adding a lot of ambiguity. imho,
the trade off is not worth it. but we still make it possible for you
to shoot yourself in the foot if you choose to do so :)

-igor



 igor.vaynberg wrote:

 in our app components with id feedbackPanel are often used to present
 a user with a user-feedback panel they can use to submit
 suggestions...

 -igor

 On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
 [EMAIL PROTECTED] wrote:

 Hi Martijin,
 First of all thank you for your response.
 I guess automation != magic. Automation means that computers or
 frameworks
 helps humans accomplishing repetitive tasks, so developers can better
 focus
 on the problem being solved, rather than having to copy and paste same
 code
 over and over (boilerplate).
 If one add a markup named feedbackPanel, what is he intent, to make a
 combo
 box? Or he have to tell it again, in a different way? IMO it's better to
 tell one time what I'm willing to do rather than 2, 3, 5...


 Martijn Dashorst wrote:

 -1000,000,000,000

 First please don't assume someone understands your acronym du jour. I
 had to think really hard to understand that CoC means convention over
 configuration instead of the Dutch meaning gay rights group.

 Second this is not a task for wicket. You can  think up any CoCamania
 you want in your own addon framework and publish it on 'stuff or
 google code, but I won't be using it ever nor including it in core.

 The biggest plus point of wicket is that it doesn't perform magic. I
 don't need nor want to have to wave a dead chicken in front of my
 monitor and spend the bigger part of the day wondering which
 incantation I did wrong.

 Martijn
 On 11/26/08, Ricardo Mayerhofer [EMAIL PROTECTED] wrote:

 I started to use wicket some time ago, and I'm really enjoying it. Best
 framework ever.
 But I've some suggestions.
 I think wicket could be better if it had less boiler plate code. This
 could
 be reduced by using CoC.
 Take the FeedBackPanel for example, you always have to add the
 component
 on
 the web page, even if no special handling is requires (which is almost
 the
 case).
 Wicket could have some reserved ids, so if I add a markup with id
 feedbackPanel, a feedbackpanel component is automatically added to that
 page.
 Another example is SubmitLink component. No special handling required,
 but
 for wicket sake the developer must add it on the java the page.
 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.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]




 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.4 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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




 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.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 

Re: Using CompoundPropertyModel with FormComponentPanel

2008-11-26 Thread Ned Collyer

Bupbow. - that Yields an exception because the FormComponentPanels model
object is of type String - not user.

editor = new TextFieldT(editor, new PropertyModelT(this,
String.format(model.object.%s, id)));

org.apache.wicket.WicketRuntimeException: No get method defined for class:
class java.lang.String expression: name

Rgds

Ned




igor.vaynberg wrote:
 
 String.format(model.object.%s, id)));
 
 

-- 
View this message in context: 
http://www.nabble.com/Using-CompoundPropertyModel-with-FormComponentPanel-tp20697019p20709911.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: Wicket and CoC

2008-11-26 Thread jWeekend

Richardo,

That's one way of thinking. And I agree Bob Martin has some interesting
generic ideas/guidelines for developers starting out. 
I have a lot of faith in the Wicket core devs and I tend to agree with most
all the decisions they take (often after a lot of instructive and
constructive discussion). However, if it turns out that your ideas on this
matter and the implementation of it can save hours of developer time while
not reducing the quality of this (serious) framework or the experience, I am
sure I would make time to look at it.

Regards - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk 



Ricardo Mayerhofer wrote:
 
 Perhaps the name could be userFeedBackPanel :) 
 One Word per Concept (Clean Code, Bob Martin, p. 26)
 
 I'm just talking about code duplication, add( new SubmitLink( submitLink
 ) ) and similars many times in a code doenst makes a programmer happier.
 OOP (object oriented programming) isn't always the best tools to solve
 code duplication. So sometimes AOP (aspect oriented programming) comes to
 mind, other times CoC (convention over configuration). (I hope Martijn is
 happy by the acronyms explanations :)).
 
 I'm not saying that it should be in wicket core (as you guys keep it thin
 as you can) and I'm glad wicket core makes me able to extend it, in a way
 I can implement this (thats a huge plus)
 
 I'm just saying that this is not a bad idea, mainly when you care about
 saving programming efforts and clean code. 
 
 
 igor.vaynberg wrote:
 
 in our app components with id feedbackPanel are often used to present
 a user with a user-feedback panel they can use to submit
 suggestions...
 
 -igor
 
 On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
 [EMAIL PROTECTED] wrote:

 Hi Martijin,
 First of all thank you for your response.
 I guess automation != magic. Automation means that computers or
 frameworks
 helps humans accomplishing repetitive tasks, so developers can better
 focus
 on the problem being solved, rather than having to copy and paste same
 code
 over and over (boilerplate).
 If one add a markup named feedbackPanel, what is he intent, to make a
 combo
 box? Or he have to tell it again, in a different way? IMO it's better to
 tell one time what I'm willing to do rather than 2, 3, 5...


 Martijn Dashorst wrote:

 -1000,000,000,000

 First please don't assume someone understands your acronym du jour. I
 had to think really hard to understand that CoC means convention over
 configuration instead of the Dutch meaning gay rights group.

 Second this is not a task for wicket. You can  think up any CoCamania
 you want in your own addon framework and publish it on 'stuff or
 google code, but I won't be using it ever nor including it in core.

 The biggest plus point of wicket is that it doesn't perform magic. I
 don't need nor want to have to wave a dead chicken in front of my
 monitor and spend the bigger part of the day wondering which
 incantation I did wrong.

 Martijn
 On 11/26/08, Ricardo Mayerhofer [EMAIL PROTECTED] wrote:

 I started to use wicket some time ago, and I'm really enjoying it.
 Best
 framework ever.
 But I've some suggestions.
 I think wicket could be better if it had less boiler plate code. This
 could
 be reduced by using CoC.
 Take the FeedBackPanel for example, you always have to add the
 component
 on
 the web page, even if no special handling is requires (which is almost
 the
 case).
 Wicket could have some reserved ids, so if I add a markup with id
 feedbackPanel, a feedbackpanel component is automatically added to
 that
 page.
 Another example is SubmitLink component. No special handling required,
 but
 for wicket sake the developer must add it on the java the page.
 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.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]




 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.4 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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




 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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


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

-- 
View this message in context: 
http://www.nabble.com/Wicket-and-CoC-tp20706881p20709922.html
Sent from 

Re: Wicket Session grows too big real fast

2008-11-26 Thread jWeekend

Martijn,

If you can put a little bit more meat on this, or give a stronger hint where
to start looking, I'd like to add something to the 
http://cwiki.apache.org/confluence/display/WICKET/Wicket+Session+Size Wicket
Session Size Wiki page . See the Keeping a reference to the previous page
section.

Regards - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk 
PS I sent email on another matter to your personal email address.



Martijn Dashorst wrote:
 
 iirc there a method to get the previous page from the page map without
 keeping a reference. Search the list for such a thing. Something with
 PageId or such.
 
 Martijn
 
 /me curses memory leakage in himself
 
 On Wed, Nov 26, 2008 at 10:35 AM, jhp [EMAIL PROTECTED] wrote:

 Well, yes references to pages seems to be given as constructor arguments
 to
 several pages. The idea is that if 'Cancel' is clicked, application goes
 back to previous page. The possibility to go back more than one page is
 not
 necessary. Is the correct way to implement cancle with some javascript
 that
 does something like user clicking previous page?

 Jukka


 Martijn Dashorst wrote:

 With Wicket 1.3 only one page should be stored in session. You should
 check if you don't keep references between pages - that would result
 in 1+N pages (with N being the number of pages you reference in your
 page).

 Other than that: using LDM's and DataView/DataProvider instead of
 ListView will help considerably.

 Martijn



 --
 View this message in context:
 http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697523.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]


 
 
 
 -- 
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.4 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20710054.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: Wicket and CoC

2008-11-26 Thread jWeekend

Richardo,

If you are serious about looking into RADifying extension to Wicket, here
are a couple of resources that may be interesting:

http://herebebeasties.com Al Maw' s excellent 
http://londonwicket.org/content/LondonWicket-FormsWithFlair.pdf Forms with
Flair  presentation
http://faler.wordpress.com/ Wille Faler 's neat 
http://sites.google.com/site/wicketrad/ Wicket RAD  project 
http://wicketwebbeans.sourceforge.net/ Wicket Web Beans  (haven't met the
author of this one)

Regards - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk 




Ricardo Mayerhofer wrote:
 
 Perhaps the name could be userFeedBackPanel :) 
 One Word per Concept (Clean Code, Bob Martin, p. 26)
 
 I'm just talking about code duplication, add( new SubmitLink( submitLink
 ) ) and similars many times in a code doenst makes a programmer happier.
 OOP (object oriented programming) isn't always the best tools to solve
 code duplication. So sometimes AOP (aspect oriented programming) comes to
 mind, other times CoC (convention over configuration). (I hope Martijn is
 happy by the acronyms explanations :)).
 
 I'm not saying that it should be in wicket core (as you guys keep it thin
 as you can) and I'm glad wicket core makes me able to extend it, in a way
 I can implement this (thats a huge plus)
 
 I'm just saying that this is not a bad idea, mainly when you care about
 saving programming efforts and clean code. 
 
 
 igor.vaynberg wrote:
 
 in our app components with id feedbackPanel are often used to present
 a user with a user-feedback panel they can use to submit
 suggestions...
 
 -igor
 
 On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
 [EMAIL PROTECTED] wrote:

 Hi Martijin,
 First of all thank you for your response.
 I guess automation != magic. Automation means that computers or
 frameworks
 helps humans accomplishing repetitive tasks, so developers can better
 focus
 on the problem being solved, rather than having to copy and paste same
 code
 over and over (boilerplate).
 If one add a markup named feedbackPanel, what is he intent, to make a
 combo
 box? Or he have to tell it again, in a different way? IMO it's better to
 tell one time what I'm willing to do rather than 2, 3, 5...


 Martijn Dashorst wrote:

 -1000,000,000,000

 First please don't assume someone understands your acronym du jour. I
 had to think really hard to understand that CoC means convention over
 configuration instead of the Dutch meaning gay rights group.

 Second this is not a task for wicket. You can  think up any CoCamania
 you want in your own addon framework and publish it on 'stuff or
 google code, but I won't be using it ever nor including it in core.

 The biggest plus point of wicket is that it doesn't perform magic. I
 don't need nor want to have to wave a dead chicken in front of my
 monitor and spend the bigger part of the day wondering which
 incantation I did wrong.

 Martijn
 On 11/26/08, Ricardo Mayerhofer [EMAIL PROTECTED] wrote:

 I started to use wicket some time ago, and I'm really enjoying it.
 Best
 framework ever.
 But I've some suggestions.
 I think wicket could be better if it had less boiler plate code. This
 could
 be reduced by using CoC.
 Take the FeedBackPanel for example, you always have to add the
 component
 on
 the web page, even if no special handling is requires (which is almost
 the
 case).
 Wicket could have some reserved ids, so if I add a markup with id
 feedbackPanel, a feedbackpanel component is automatically added to
 that
 page.
 Another example is SubmitLink component. No special handling required,
 but
 for wicket sake the developer must add it on the java the page.
 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.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]




 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.4 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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




 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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


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

-- 
View this message in context: 
http://www.nabble.com/Wicket-and-CoC-tp20706881p20710279.html
Sent from the Wicket - User mailing list archive at Nabble.com.



Re: Using CompoundPropertyModel with FormComponentPanel

2008-11-26 Thread Igor Vaynberg
then justmodel.object will do :)

-igor

On Wed, Nov 26, 2008 at 2:08 PM, Ned Collyer [EMAIL PROTECTED] wrote:

 Bupbow. - that Yields an exception because the FormComponentPanels model
 object is of type String - not user.

 editor = new TextFieldT(editor, new PropertyModelT(this,
 String.format(model.object.%s, id)));

 org.apache.wicket.WicketRuntimeException: No get method defined for class:
 class java.lang.String expression: name

 Rgds

 Ned




 igor.vaynberg wrote:

 String.format(model.object.%s, id)));



 --
 View this message in context: 
 http://www.nabble.com/Using-CompoundPropertyModel-with-FormComponentPanel-tp20697019p20709911.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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



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



Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

2008-11-26 Thread James Carman
But, here you have to assume it was released from the trunk (which I guess
you can ascertain from the pom's SVN url).  I'm not saying this information
isn't useful.  I'm just saying it doesn't give you the whole picture by
itself.  I was unaware of this plugin, but I do believe I'll add it to our
build cycle.  Thanks for the tip!

On Wed, Nov 26, 2008 at 4:18 PM, Ryan McKinley [EMAIL PROTECTED] wrote:

 Right, the svn url is important especially when you deploy from
 'non-released' versions (like most of wicketstuff)

 This is what I have in my pom.xml


plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-jar-plugin/artifactId
  configuration
archive
  manifestEntries
  Specification-Title${project.name}/Specification-Title

  Specification-Version${project.version}/Specification-Version
  Implementation-Title${project.name}/Implementation-Title
  Implementation-Version${project.version} ${buildNumber} - ${
 user.name}/Implementation-Version
  SCM-Revision${buildNumber}/SCM-Revision
  SCM-url${scm.url}/SCM-url
  /manifestEntries
/archive
  /configuration
/plugin



 On Nov 26, 2008, at 3:24 PM, James Carman wrote:

  The revision doesn't tell you everything, though.  Typically, you don't
 release from trunk (at least you're not supposed to).  You create a tag
 and create the release from there.  So, the tag/revision would be what you
 need to easily recreate the release.

 On Wed, Nov 26, 2008 at 2:13 PM, Ryan McKinley [EMAIL PROTECTED] wrote:


 On Nov 26, 2008, at 11:38 AM, Jeremy Thomerson wrote:

 I think Wayne was referring not to your post, but in general - if we

 package
 most of the projects up neatly under one parent, then other projects
 that
 aren't in the same subdirectory / build cycle may get lost.


 Hopefully having a cleaned up source tree with better pom/version reuse
 will make it much easier to keep things up-to-date and useful.  It should
 not be that hard to clean up most of the existing projects.

 Another thing that would be nice to add to the parent pom is:


 http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html

 I have found it invaluable to have the SVN version cooked into the
 artifacts -- particularly after something has been running stable for a
 year
 and you can't possibly remember exactly where it came from.

 ryan




  --
 Jeremy Thomerson
 http://www.wickettraining.com


 On Wed, Nov 26, 2008 at 7:10 AM, James Carman 
 [EMAIL PROTECTED]

 wrote:


 Merely bundling the examples with the code itself shouldn't cause
 this,

 do
 you think?

 On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope 
 [EMAIL PROTECTED] wrote:

 YES.

 However I feel people may pass over the earlier branches (especially
 when
 we're on Wicket version 5.8!) and hence miss some great code that may
 not
 take much to get working and maintain on the newer branch.

 On Wed, Nov 26, 2008 at 2:06 AM, James Carman 

  [EMAIL PROTECTED]

  wrote:



 Yes, our entire project at work is like this.  The top-level project

 holds multiple modules.  Each has a common, server, and client
 submodule.  Works like a charm.

 On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson
 [EMAIL PROTECTED] wrote:

  Great idea!  Yes.  I have not nested any projects three deep in the

  past,


  but it should work.  Has anybody else tried this?


 It would be:

 wicket-stuff-parent
 -- wicket-foo
  -- wicket-foo-core
  -- wicket-foo-examples

 On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED]

  wrote:


 I don't know if this has already been discussed, but another part of


  the


  cleanup that would be nice is to group the main project and the


  example


  project into a folder with a common parent pom.


 For example, I find the layout of:






 https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/


  much easier to use/maintain then the apparent standard of
 /wicketstuff-project  /wicketstuff-project-example






 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/


  one key thing about this change is that mvn eclipse:eclipse makes

  the


  example project depend on the core project


 perhaps this could be added to the 'organize' task?

 ryan





 -


  To unsubscribe, e-mail: [EMAIL PROTECTED]

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




 --
 Jeremy Thomerson
 http://www.wickettraining.com


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 

Re: Using CompoundPropertyModel with FormComponentPanel

2008-11-26 Thread Ned Collyer

FYI, you are awesome.

Always obvious what the problem is after its fixed hey ;)


igor.vaynberg wrote:
 
 then justmodel.object will do :)
 
 -igor
 

-- 
View this message in context: 
http://www.nabble.com/Using-CompoundPropertyModel-with-FormComponentPanel-tp20697019p20710669.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: Wicket and CoC

2008-11-26 Thread wfaler

Speaking of which, I'd be happy to get help with Wicket RAD. :)
Especially in the area of making look-and-feel more customizable/flexible,
but other ideas are also welcome of course. Help with documentation would
also be very, very welcome. :D

Have a new release in the works, just been a bit snowed under of late. After
the next release I'm looking at upgrading the underlying Wicket
implementation to 1.4.


jWeekend wrote:
 
 Richardo,
 
 If you are serious about looking into RADifying extension to Wicket, here
 are a couple of resources that may be interesting:
 
  http://herebebeasties.com Al Maw' s excellent 
 http://londonwicket.org/content/LondonWicket-FormsWithFlair.pdf Forms with
 Flair  presentation
  http://faler.wordpress.com/ Wille Faler 's neat 
 http://sites.google.com/site/wicketrad/ Wicket RAD  project 
  http://wicketwebbeans.sourceforge.net/ Wicket Web Beans  (haven't met the
 author of this one)
 
 Regards - Cemal
  http://www.jWeekend.co.uk http://jWeekend.co.uk 
 
 
 
 
 Ricardo Mayerhofer wrote:
 
 Perhaps the name could be userFeedBackPanel :) 
 One Word per Concept (Clean Code, Bob Martin, p. 26)
 
 I'm just talking about code duplication, add( new SubmitLink(
 submitLink ) ) and similars many times in a code doenst makes a
 programmer happier.
 OOP (object oriented programming) isn't always the best tools to solve
 code duplication. So sometimes AOP (aspect oriented programming) comes to
 mind, other times CoC (convention over configuration). (I hope Martijn is
 happy by the acronyms explanations :)).
 
 I'm not saying that it should be in wicket core (as you guys keep it thin
 as you can) and I'm glad wicket core makes me able to extend it, in a way
 I can implement this (thats a huge plus)
 
 I'm just saying that this is not a bad idea, mainly when you care about
 saving programming efforts and clean code. 
 
 
 igor.vaynberg wrote:
 
 in our app components with id feedbackPanel are often used to present
 a user with a user-feedback panel they can use to submit
 suggestions...
 
 -igor
 
 On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
 [EMAIL PROTECTED] wrote:

 Hi Martijin,
 First of all thank you for your response.
 I guess automation != magic. Automation means that computers or
 frameworks
 helps humans accomplishing repetitive tasks, so developers can better
 focus
 on the problem being solved, rather than having to copy and paste same
 code
 over and over (boilerplate).
 If one add a markup named feedbackPanel, what is he intent, to make a
 combo
 box? Or he have to tell it again, in a different way? IMO it's better
 to
 tell one time what I'm willing to do rather than 2, 3, 5...


 Martijn Dashorst wrote:

 -1000,000,000,000

 First please don't assume someone understands your acronym du jour. I
 had to think really hard to understand that CoC means convention over
 configuration instead of the Dutch meaning gay rights group.

 Second this is not a task for wicket. You can  think up any CoCamania
 you want in your own addon framework and publish it on 'stuff or
 google code, but I won't be using it ever nor including it in core.

 The biggest plus point of wicket is that it doesn't perform magic. I
 don't need nor want to have to wave a dead chicken in front of my
 monitor and spend the bigger part of the day wondering which
 incantation I did wrong.

 Martijn
 On 11/26/08, Ricardo Mayerhofer [EMAIL PROTECTED] wrote:

 I started to use wicket some time ago, and I'm really enjoying it.
 Best
 framework ever.
 But I've some suggestions.
 I think wicket could be better if it had less boiler plate code. This
 could
 be reduced by using CoC.
 Take the FeedBackPanel for example, you always have to add the
 component
 on
 the web page, even if no special handling is requires (which is
 almost
 the
 case).
 Wicket could have some reserved ids, so if I add a markup with id
 feedbackPanel, a feedbackpanel component is automatically added to
 that
 page.
 Another example is SubmitLink component. No special handling
 required,
 but
 for wicket sake the developer must add it on the java the page.
 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.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]




 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.4 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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




 --
 View this message in context:
 http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 

Re: Wicket and CoC

2008-11-26 Thread Ricardo Mayerhofer

Hi Igor,
User feedback is different from Feedback Panel, and I think is this
difference is good, otherwise you will use one word with two meanings under
the same project (I think I just defined ambiguity :)).

Think about a project that uses a API that has a name for a concept and the
application has the same name for another concept:

String getB() {
return externalApi.getA(...);
}

String getA() {
return externalApi.getB(...);
}


or

add( new FeedBackPanel( userFormResponse ) )
add( new TextArea( feedBackPanel ) )

I've seen the first in a project, it confuses people.

And of course. frameworks doesn't dictateds application domain, because
technical things and domain things are different. Your user will never ask,
hey creates a send to server clickable here for me (user name for submit
link). 

CoC doesn't mean Convention Only or Convention Instead Configuration. Its
purpose is to speed up development in most cases and keep the same effort,
as if it was not there, on the other cases. If someone wants to extend
submit link, no problem just do it and add it on the java page.


igor.vaynberg wrote:
 
 On Wed, Nov 26, 2008 at 1:57 PM, Ricardo Mayerhofer
 [EMAIL PROTECTED] wrote:

 Perhaps the name could be userFeedBackPanel :)
 One Word per Concept (Clean Code, Bob Martin, p. 26)
 
 why should conventions of a framework we use dictate our names in the
 application domain? within our application user feedback is a well
 known term. so just because we are using wicket we should change it?
 this is why stuff like that doesnt go into core :)
 
 I'm just talking about code duplication, add( new SubmitLink(
 submitLink )
 ) and similars many times in a code doenst makes a programmer happier.
 OOP (object oriented programming) isn't always the best tools to solve
 code
 duplication. So sometimes AOP (aspect oriented programming) comes to
 mind,
 other times CoC (convention over configuration). (I hope Martijn is happy
 by
 the acronyms explanations :)).

 I'm not saying that it should be in wicket core (as you guys keep it thin
 as
 you can) and I'm glad wicket core makes me able to extend it, in a way I
 can
 implement this (thats a huge plus)
 
 this kind of stuff adds ambiguity - that is mostly why it doesnt make
 it into core. you say submitLink creates a component, fine, but in
 our app we have our own subclass of SubmitLink we use that includes
 our css styles, indicators, etc - which again breaks with your
 suggestion.
 
 I'm just saying that this is not a bad idea, mainly when you care about
 saving programming efforts and clean code.
 
 you are saving a few lines of code by adding a lot of ambiguity. imho,
 the trade off is not worth it. but we still make it possible for you
 to shoot yourself in the foot if you choose to do so :)
 
 -igor
 


 igor.vaynberg wrote:

 in our app components with id feedbackPanel are often used to present
 a user with a user-feedback panel they can use to submit
 suggestions...

 -igor

 On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
 [EMAIL PROTECTED] wrote:

 Hi Martijin,
 First of all thank you for your response.
 I guess automation != magic. Automation means that computers or
 frameworks
 helps humans accomplishing repetitive tasks, so developers can better
 focus
 on the problem being solved, rather than having to copy and paste same
 code
 over and over (boilerplate).
 If one add a markup named feedbackPanel, what is he intent, to make a
 combo
 box? Or he have to tell it again, in a different way? IMO it's better
 to
 tell one time what I'm willing to do rather than 2, 3, 5...


 Martijn Dashorst wrote:

 -1000,000,000,000

 First please don't assume someone understands your acronym du jour. I
 had to think really hard to understand that CoC means convention over
 configuration instead of the Dutch meaning gay rights group.

 Second this is not a task for wicket. You can  think up any CoCamania
 you want in your own addon framework and publish it on 'stuff or
 google code, but I won't be using it ever nor including it in core.

 The biggest plus point of wicket is that it doesn't perform magic. I
 don't need nor want to have to wave a dead chicken in front of my
 monitor and spend the bigger part of the day wondering which
 incantation I did wrong.

 Martijn
 On 11/26/08, Ricardo Mayerhofer [EMAIL PROTECTED] wrote:

 I started to use wicket some time ago, and I'm really enjoying it.
 Best
 framework ever.
 But I've some suggestions.
 I think wicket could be better if it had less boiler plate code. This
 could
 be reduced by using CoC.
 Take the FeedBackPanel for example, you always have to add the
 component
 on
 the web page, even if no special handling is requires (which is
 almost
 the
 case).
 Wicket could have some reserved ids, so if I add a markup with id
 feedbackPanel, a feedbackpanel component is automatically added to
 that
 page.
 Another example is SubmitLink component. No special handling
 required,
 but
 for wicket sake the 

Re: Wicket and CoC

2008-11-26 Thread Igor Vaynberg
right, so i should rename concepts from code that was written before
wicket just because we are using wicket now...

-igor

On Wed, Nov 26, 2008 at 3:32 PM, Ricardo Mayerhofer
[EMAIL PROTECTED] wrote:

 Hi Igor,
 User feedback is different from Feedback Panel, and I think is this
 difference is good, otherwise you will use one word with two meanings under
 the same project (I think I just defined ambiguity :)).

 Think about a project that uses a API that has a name for a concept and the
 application has the same name for another concept:

 String getB() {
return externalApi.getA(...);
 }

 String getA() {
return externalApi.getB(...);
 }


 or

 add( new FeedBackPanel( userFormResponse ) )
 add( new TextArea( feedBackPanel ) )

 I've seen the first in a project, it confuses people.

 And of course. frameworks doesn't dictateds application domain, because
 technical things and domain things are different. Your user will never ask,
 hey creates a send to server clickable here for me (user name for submit
 link).

 CoC doesn't mean Convention Only or Convention Instead Configuration. Its
 purpose is to speed up development in most cases and keep the same effort,
 as if it was not there, on the other cases. If someone wants to extend
 submit link, no problem just do it and add it on the java page.


 igor.vaynberg wrote:

 On Wed, Nov 26, 2008 at 1:57 PM, Ricardo Mayerhofer
 [EMAIL PROTECTED] wrote:

 Perhaps the name could be userFeedBackPanel :)
 One Word per Concept (Clean Code, Bob Martin, p. 26)

 why should conventions of a framework we use dictate our names in the
 application domain? within our application user feedback is a well
 known term. so just because we are using wicket we should change it?
 this is why stuff like that doesnt go into core :)

 I'm just talking about code duplication, add( new SubmitLink(
 submitLink )
 ) and similars many times in a code doenst makes a programmer happier.
 OOP (object oriented programming) isn't always the best tools to solve
 code
 duplication. So sometimes AOP (aspect oriented programming) comes to
 mind,
 other times CoC (convention over configuration). (I hope Martijn is happy
 by
 the acronyms explanations :)).

 I'm not saying that it should be in wicket core (as you guys keep it thin
 as
 you can) and I'm glad wicket core makes me able to extend it, in a way I
 can
 implement this (thats a huge plus)

 this kind of stuff adds ambiguity - that is mostly why it doesnt make
 it into core. you say submitLink creates a component, fine, but in
 our app we have our own subclass of SubmitLink we use that includes
 our css styles, indicators, etc - which again breaks with your
 suggestion.

 I'm just saying that this is not a bad idea, mainly when you care about
 saving programming efforts and clean code.

 you are saving a few lines of code by adding a lot of ambiguity. imho,
 the trade off is not worth it. but we still make it possible for you
 to shoot yourself in the foot if you choose to do so :)

 -igor



 igor.vaynberg wrote:

 in our app components with id feedbackPanel are often used to present
 a user with a user-feedback panel they can use to submit
 suggestions...

 -igor

 On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
 [EMAIL PROTECTED] wrote:

 Hi Martijin,
 First of all thank you for your response.
 I guess automation != magic. Automation means that computers or
 frameworks
 helps humans accomplishing repetitive tasks, so developers can better
 focus
 on the problem being solved, rather than having to copy and paste same
 code
 over and over (boilerplate).
 If one add a markup named feedbackPanel, what is he intent, to make a
 combo
 box? Or he have to tell it again, in a different way? IMO it's better
 to
 tell one time what I'm willing to do rather than 2, 3, 5...


 Martijn Dashorst wrote:

 -1000,000,000,000

 First please don't assume someone understands your acronym du jour. I
 had to think really hard to understand that CoC means convention over
 configuration instead of the Dutch meaning gay rights group.

 Second this is not a task for wicket. You can  think up any CoCamania
 you want in your own addon framework and publish it on 'stuff or
 google code, but I won't be using it ever nor including it in core.

 The biggest plus point of wicket is that it doesn't perform magic. I
 don't need nor want to have to wave a dead chicken in front of my
 monitor and spend the bigger part of the day wondering which
 incantation I did wrong.

 Martijn
 On 11/26/08, Ricardo Mayerhofer [EMAIL PROTECTED] wrote:

 I started to use wicket some time ago, and I'm really enjoying it.
 Best
 framework ever.
 But I've some suggestions.
 I think wicket could be better if it had less boiler plate code. This
 could
 be reduced by using CoC.
 Take the FeedBackPanel for example, you always have to add the
 component
 on
 the web page, even if no special handling is requires (which is
 almost
 the
 case).
 Wicket could have some reserved ids, 

Re: Wicket and CoC

2008-11-26 Thread Ricardo Mayerhofer

I think if you decide to rewrite an existing application with wicket, the
names will be your least problem
(http://chadfowler.com/2006/12/27/the-big-rewrite). Even though you can use
the configuration part of CoC...


igor.vaynberg wrote:
 
 right, so i should rename concepts from code that was written before
 wicket just because we are using wicket now...
 
 -igor
 
 On Wed, Nov 26, 2008 at 3:32 PM, Ricardo Mayerhofer
 [EMAIL PROTECTED] wrote:

 Hi Igor,
 User feedback is different from Feedback Panel, and I think is this
 difference is good, otherwise you will use one word with two meanings
 under
 the same project (I think I just defined ambiguity :)).

 Think about a project that uses a API that has a name for a concept and
 the
 application has the same name for another concept:

 String getB() {
return externalApi.getA(...);
 }

 String getA() {
return externalApi.getB(...);
 }


 or

 add( new FeedBackPanel( userFormResponse ) )
 add( new TextArea( feedBackPanel ) )

 I've seen the first in a project, it confuses people.

 And of course. frameworks doesn't dictateds application domain, because
 technical things and domain things are different. Your user will never
 ask,
 hey creates a send to server clickable here for me (user name for
 submit
 link).

 CoC doesn't mean Convention Only or Convention Instead Configuration. Its
 purpose is to speed up development in most cases and keep the same
 effort,
 as if it was not there, on the other cases. If someone wants to extend
 submit link, no problem just do it and add it on the java page.


 igor.vaynberg wrote:

 On Wed, Nov 26, 2008 at 1:57 PM, Ricardo Mayerhofer
 [EMAIL PROTECTED] wrote:

 Perhaps the name could be userFeedBackPanel :)
 One Word per Concept (Clean Code, Bob Martin, p. 26)

 why should conventions of a framework we use dictate our names in the
 application domain? within our application user feedback is a well
 known term. so just because we are using wicket we should change it?
 this is why stuff like that doesnt go into core :)

 I'm just talking about code duplication, add( new SubmitLink(
 submitLink )
 ) and similars many times in a code doenst makes a programmer happier.
 OOP (object oriented programming) isn't always the best tools to solve
 code
 duplication. So sometimes AOP (aspect oriented programming) comes to
 mind,
 other times CoC (convention over configuration). (I hope Martijn is
 happy
 by
 the acronyms explanations :)).

 I'm not saying that it should be in wicket core (as you guys keep it
 thin
 as
 you can) and I'm glad wicket core makes me able to extend it, in a way
 I
 can
 implement this (thats a huge plus)

 this kind of stuff adds ambiguity - that is mostly why it doesnt make
 it into core. you say submitLink creates a component, fine, but in
 our app we have our own subclass of SubmitLink we use that includes
 our css styles, indicators, etc - which again breaks with your
 suggestion.

 I'm just saying that this is not a bad idea, mainly when you care about
 saving programming efforts and clean code.

 you are saving a few lines of code by adding a lot of ambiguity. imho,
 the trade off is not worth it. but we still make it possible for you
 to shoot yourself in the foot if you choose to do so :)

 -igor



 igor.vaynberg wrote:

 in our app components with id feedbackPanel are often used to present
 a user with a user-feedback panel they can use to submit
 suggestions...

 -igor

 On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
 [EMAIL PROTECTED] wrote:

 Hi Martijin,
 First of all thank you for your response.
 I guess automation != magic. Automation means that computers or
 frameworks
 helps humans accomplishing repetitive tasks, so developers can better
 focus
 on the problem being solved, rather than having to copy and paste
 same
 code
 over and over (boilerplate).
 If one add a markup named feedbackPanel, what is he intent, to make a
 combo
 box? Or he have to tell it again, in a different way? IMO it's better
 to
 tell one time what I'm willing to do rather than 2, 3, 5...


 Martijn Dashorst wrote:

 -1000,000,000,000

 First please don't assume someone understands your acronym du jour.
 I
 had to think really hard to understand that CoC means convention
 over
 configuration instead of the Dutch meaning gay rights group.

 Second this is not a task for wicket. You can  think up any
 CoCamania
 you want in your own addon framework and publish it on 'stuff or
 google code, but I won't be using it ever nor including it in core.

 The biggest plus point of wicket is that it doesn't perform magic. I
 don't need nor want to have to wave a dead chicken in front of my
 monitor and spend the bigger part of the day wondering which
 incantation I did wrong.

 Martijn
 On 11/26/08, Ricardo Mayerhofer [EMAIL PROTECTED]
 wrote:

 I started to use wicket some time ago, and I'm really enjoying it.
 Best
 framework ever.
 But I've some suggestions.
 I think wicket could be better if it had 

Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

2008-11-26 Thread Jurek Piasek
It is easy to vote yes to this.

On Wed, Nov 26, 2008 at 5:55 PM, James Carman [EMAIL PROTECTED]wrote:

 But, here you have to assume it was released from the trunk (which I guess
 you can ascertain from the pom's SVN url).  I'm not saying this information
 isn't useful.  I'm just saying it doesn't give you the whole picture by
 itself.  I was unaware of this plugin, but I do believe I'll add it to our
 build cycle.  Thanks for the tip!

 On Wed, Nov 26, 2008 at 4:18 PM, Ryan McKinley [EMAIL PROTECTED] wrote:

  Right, the svn url is important especially when you deploy from
  'non-released' versions (like most of wicketstuff)
 
  This is what I have in my pom.xml
 
 
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-jar-plugin/artifactId
   configuration
 archive
   manifestEntries
   Specification-Title${project.name}/Specification-Title
 
   Specification-Version${project.version}/Specification-Version
   Implementation-Title${project.name
 }/Implementation-Title
   Implementation-Version${project.version} ${buildNumber} -
 ${
  user.name}/Implementation-Version
   SCM-Revision${buildNumber}/SCM-Revision
   SCM-url${scm.url}/SCM-url
   /manifestEntries
 /archive
   /configuration
 /plugin
 
 
 
  On Nov 26, 2008, at 3:24 PM, James Carman wrote:
 
   The revision doesn't tell you everything, though.  Typically, you don't
  release from trunk (at least you're not supposed to).  You create a
 tag
  and create the release from there.  So, the tag/revision would be what
 you
  need to easily recreate the release.
 
  On Wed, Nov 26, 2008 at 2:13 PM, Ryan McKinley [EMAIL PROTECTED]
 wrote:
 
 
  On Nov 26, 2008, at 11:38 AM, Jeremy Thomerson wrote:
 
  I think Wayne was referring not to your post, but in general - if we
 
  package
  most of the projects up neatly under one parent, then other projects
  that
  aren't in the same subdirectory / build cycle may get lost.
 
 
  Hopefully having a cleaned up source tree with better pom/version reuse
  will make it much easier to keep things up-to-date and useful.  It
 should
  not be that hard to clean up most of the existing projects.
 
  Another thing that would be nice to add to the parent pom is:
 
 
 
 http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html
 
  I have found it invaluable to have the SVN version cooked into the
  artifacts -- particularly after something has been running stable for a
  year
  and you can't possibly remember exactly where it came from.
 
  ryan
 
 
 
 
   --
  Jeremy Thomerson
  http://www.wickettraining.com
 
 
  On Wed, Nov 26, 2008 at 7:10 AM, James Carman 
  [EMAIL PROTECTED]
 
  wrote:
 
 
  Merely bundling the examples with the code itself shouldn't cause
  this,
 
  do
  you think?
 
  On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope 
  [EMAIL PROTECTED] wrote:
 
  YES.
 
  However I feel people may pass over the earlier branches (especially
  when
  we're on Wicket version 5.8!) and hence miss some great code that
 may
  not
  take much to get working and maintain on the newer branch.
 
  On Wed, Nov 26, 2008 at 2:06 AM, James Carman 
 
   [EMAIL PROTECTED]
 
   wrote:
 
 
 
  Yes, our entire project at work is like this.  The top-level project
 
  holds multiple modules.  Each has a common, server, and client
  submodule.  Works like a charm.
 
  On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson
  [EMAIL PROTECTED] wrote:
 
   Great idea!  Yes.  I have not nested any projects three deep in
 the
 
   past,
 
 
   but it should work.  Has anybody else tried this?
 
 
  It would be:
 
  wicket-stuff-parent
  -- wicket-foo
   -- wicket-foo-core
   -- wicket-foo-examples
 
  On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED]
 
 
   wrote:
 
 
  I don't know if this has already been discussed, but another part
 of
 
 
   the
 
 
   cleanup that would be nice is to group the main project and the
 
 
   example
 
 
   project into a folder with a common parent pom.
 
 
  For example, I find the layout of:
 
 
 
 
 
 
 
 https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/
 
 
   much easier to use/maintain then the apparent standard of
  /wicketstuff-project  /wicketstuff-project-example
 
 
 
 
 
 
 
 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/
 
 
   one key thing about this change is that mvn eclipse:eclipse makes
 
   the
 
 
   example project depend on the core project
 
 
  perhaps this could be added to the 'organize' task?
 
  ryan
 
 
 
 
 
 
 

Re: continueToOriginalDestination and POST

2008-11-26 Thread kan
Yes, I am talking about timeouts.
Actually... Maybe I want from wicket more than it was designed for. In
some cases state of web-application could be on client-side and
doesn't need to be in server-side session, only exception is
auth-data. And I don't like fact that user faces with page expired
error message or losses post data.
But maybe yes, easier would be just make a periodic poll to keep session.

2008/11/26 Jeremy Thomerson [EMAIL PROTECTED]:
 You could add a feature request (and a patch?).

 My point was don't let them start on the form until they are signed in if
 being signed in is required for submitting the form.  This just makes sense.

 Or, if what you're saying is that they are timing out while working on the
 form, add an ajax update behavior that will keep them signed in / session
 current.

 On Wed, Nov 26, 2008 at 12:36 PM, kan [EMAIL PROTECTED] wrote:

 A user has started to work with the form, then was distracted for 20
 minutes, then he comes back and presses submit.
 Is it difficult to store PageParameters too?

 2008/11/26 Jeremy Thomerson [EMAIL PROTECTED]:
   They shouldn't be able to access the bookmarkable page with the form
 (or,
  access the page, but have the form hidden until signed-in).  For
  continueToOriginalDestination, IIRC, Wicket just stores the URL, so you
  can't go back to a POST.
 
  On Wed, Nov 26, 2008 at 10:27 AM, kan [EMAIL PROTECTED] wrote:
 
  I have a site which requires authentication. I've made it via
  @AuthorizeInstantiation.
  Works well. But if a bookmarkable page has a form with method POST,
  and user presses submit after timeout, it redirects him to SignIn
  screen. After successful login the site redirects back (usinig
  continueToOriginalDestination) to the page and happens not very good
  thing - method on form onSubmit is called but with no data on it,
  because POST is lost during that redirects. Is there any easy reliable
  solution of the problem?
 
  --
  WBR, kan.
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
  --
  Jeremy Thomerson
  http://www.wickettraining.com
 



 --
  WBR, kan.

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




 --
 Jeremy Thomerson
 http://www.wickettraining.com




-- 
WBR, kan.

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



Re: continueToOriginalDestination and POST

2008-11-26 Thread jWeekend

Kan,

If you are thinking of getting around this with a heartbeat, Eelco 
http://chillenious.wordpress.com/2007/06/19/how-to-create-a-text-area-with-a-heart-beat-with-wicket/
wrote about this  a while back.

Regards - Cemal
http://www.jWeekend.co.uk http://j|Weekend.co.uk 


kan-4 wrote:
 
 Yes, I am talking about timeouts.
 Actually... Maybe I want from wicket more than it was designed for. In
 some cases state of web-application could be on client-side and
 doesn't need to be in server-side session, only exception is
 auth-data. And I don't like fact that user faces with page expired
 error message or losses post data.
 But maybe yes, easier would be just make a periodic poll to keep session.
 
 2008/11/26 Jeremy Thomerson [EMAIL PROTECTED]:
 You could add a feature request (and a patch?).

 My point was don't let them start on the form until they are signed in if
 being signed in is required for submitting the form.  This just makes
 sense.

 Or, if what you're saying is that they are timing out while working on
 the
 form, add an ajax update behavior that will keep them signed in / session
 current.

 On Wed, Nov 26, 2008 at 12:36 PM, kan [EMAIL PROTECTED] wrote:

 A user has started to work with the form, then was distracted for 20
 minutes, then he comes back and presses submit.
 Is it difficult to store PageParameters too?

 2008/11/26 Jeremy Thomerson [EMAIL PROTECTED]:
   They shouldn't be able to access the bookmarkable page with the form
 (or,
  access the page, but have the form hidden until signed-in).  For
  continueToOriginalDestination, IIRC, Wicket just stores the URL, so
 you
  can't go back to a POST.
 
  On Wed, Nov 26, 2008 at 10:27 AM, kan [EMAIL PROTECTED] wrote:
 
  I have a site which requires authentication. I've made it via
  @AuthorizeInstantiation.
  Works well. But if a bookmarkable page has a form with method POST,
  and user presses submit after timeout, it redirects him to SignIn
  screen. After successful login the site redirects back (usinig
  continueToOriginalDestination) to the page and happens not very good
  thing - method on form onSubmit is called but with no data on it,
  because POST is lost during that redirects. Is there any easy
 reliable
  solution of the problem?
 
  --
  WBR, kan.
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
  --
  Jeremy Thomerson
  http://www.wickettraining.com
 



 --
  WBR, kan.

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




 --
 Jeremy Thomerson
 http://www.wickettraining.com

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

-- 
View this message in context: 
http://www.nabble.com/continueToOriginalDestination-and-POST-tp20704326p20711992.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: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

2008-11-26 Thread Ryan McKinley
yes, that is a problem with this plugin -- it looks at the configured  
pom scm and uses the info from there.  The biggest problem is that if  
you build a modified version, the revision number is from the repos,  
*not* your code!  so if 'svn info' shows Revision: 220M or 220~218,  
the cooked in version would still be 220.


In ant, I had a task that calls 'svn info' and parses the result, but  
this is the best off the shelf replacement i could find in maven.


ryan


On Nov 26, 2008, at 5:55 PM, James Carman wrote:

But, here you have to assume it was released from the trunk (which I  
guess
you can ascertain from the pom's SVN url).  I'm not saying this  
information
isn't useful.  I'm just saying it doesn't give you the whole picture  
by
itself.  I was unaware of this plugin, but I do believe I'll add it  
to our

build cycle.  Thanks for the tip!

On Wed, Nov 26, 2008 at 4:18 PM, Ryan McKinley [EMAIL PROTECTED]  
wrote:



Right, the svn url is important especially when you deploy from
'non-released' versions (like most of wicketstuff)

This is what I have in my pom.xml


  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
  archive
manifestEntries
Specification-Title${project.name}/Specification- 
Title


Specification-Version${project.version}/Specification-Version
Implementation-Title${project.name}/Implementation- 
Title
Implementation-Version${project.version} $ 
{buildNumber} - ${

user.name}/Implementation-Version
SCM-Revision${buildNumber}/SCM-Revision
SCM-url${scm.url}/SCM-url
/manifestEntries
  /archive
/configuration
  /plugin



On Nov 26, 2008, at 3:24 PM, James Carman wrote:

The revision doesn't tell you everything, though.  Typically, you  
don't
release from trunk (at least you're not supposed to).  You  
create a tag
and create the release from there.  So, the tag/revision would be  
what you

need to easily recreate the release.

On Wed, Nov 26, 2008 at 2:13 PM, Ryan McKinley [EMAIL PROTECTED]  
wrote:




On Nov 26, 2008, at 11:38 AM, Jeremy Thomerson wrote:

I think Wayne was referring not to your post, but in general - if  
we



package
most of the projects up neatly under one parent, then other  
projects

that
aren't in the same subdirectory / build cycle may get lost.


Hopefully having a cleaned up source tree with better pom/version  
reuse
will make it much easier to keep things up-to-date and useful.   
It should

not be that hard to clean up most of the existing projects.

Another thing that would be nice to add to the parent pom is:


http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html

I have found it invaluable to have the SVN version cooked into the
artifacts -- particularly after something has been running stable  
for a

year
and you can't possibly remember exactly where it came from.

ryan




--

Jeremy Thomerson
http://www.wickettraining.com


On Wed, Nov 26, 2008 at 7:10 AM, James Carman 
[EMAIL PROTECTED]


wrote:



Merely bundling the examples with the code itself shouldn't  
cause

this,


do
you think?

On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope 
[EMAIL PROTECTED] wrote:

YES.

However I feel people may pass over the earlier branches  
(especially

when
we're on Wicket version 5.8!) and hence miss some great code  
that may

not
take much to get working and maintain on the newer branch.

On Wed, Nov 26, 2008 at 2:06 AM, James Carman 

[EMAIL PROTECTED]


wrote:





Yes, our entire project at work is like this.  The top-level  
project



holds multiple modules.  Each has a common, server, and client
submodule.  Works like a charm.

On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:

Great idea!  Yes.  I have not nested any projects three deep  
in the


past,




but it should work.  Has anybody else tried this?




It would be:

wicket-stuff-parent
-- wicket-foo
-- wicket-foo-core
-- wicket-foo-examples

On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED] 



wrote:



I don't know if this has already been discussed, but another  
part of




the





cleanup that would be nice is to group the main project and the





example





project into a folder with a common parent pom.





For example, I find the layout of:









https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/



much easier to use/maintain then the apparent standard of

/wicketstuff-project  /wicketstuff-project-example









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/


one key thing about 

Re: Wicket and CoC

2008-11-26 Thread Nino Saturnino Martinez Vazquez Wael

Theres also wickettopia...

http://sourceforge.net/projects/wicketopia/

jWeekend wrote:

Richardo,

If you are serious about looking into RADifying extension to Wicket, here
are a couple of resources that may be interesting:

http://herebebeasties.com Al Maw' s excellent 
http://londonwicket.org/content/LondonWicket-FormsWithFlair.pdf Forms with

Flair  presentation
http://faler.wordpress.com/ Wille Faler 's neat 
http://sites.google.com/site/wicketrad/ Wicket RAD  project 
http://wicketwebbeans.sourceforge.net/ Wicket Web Beans  (haven't met the

author of this one)

Regards - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk 





Ricardo Mayerhofer wrote:
  
Perhaps the name could be userFeedBackPanel :) 
One Word per Concept (Clean Code, Bob Martin, p. 26)


I'm just talking about code duplication, add( new SubmitLink( submitLink
) ) and similars many times in a code doenst makes a programmer happier.
OOP (object oriented programming) isn't always the best tools to solve
code duplication. So sometimes AOP (aspect oriented programming) comes to
mind, other times CoC (convention over configuration). (I hope Martijn is
happy by the acronyms explanations :)).

I'm not saying that it should be in wicket core (as you guys keep it thin
as you can) and I'm glad wicket core makes me able to extend it, in a way
I can implement this (thats a huge plus)

I'm just saying that this is not a bad idea, mainly when you care about
saving programming efforts and clean code. 



igor.vaynberg wrote:


in our app components with id feedbackPanel are often used to present
a user with a user-feedback panel they can use to submit
suggestions...

-igor

On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
[EMAIL PROTECTED] wrote:
  

Hi Martijin,
First of all thank you for your response.
I guess automation != magic. Automation means that computers or
frameworks
helps humans accomplishing repetitive tasks, so developers can better
focus
on the problem being solved, rather than having to copy and paste same
code
over and over (boilerplate).
If one add a markup named feedbackPanel, what is he intent, to make a
combo
box? Or he have to tell it again, in a different way? IMO it's better to
tell one time what I'm willing to do rather than 2, 3, 5...


Martijn Dashorst wrote:


-1000,000,000,000

First please don't assume someone understands your acronym du jour. I
had to think really hard to understand that CoC means convention over
configuration instead of the Dutch meaning gay rights group.

Second this is not a task for wicket. You can  think up any CoCamania
you want in your own addon framework and publish it on 'stuff or
google code, but I won't be using it ever nor including it in core.

The biggest plus point of wicket is that it doesn't perform magic. I
don't need nor want to have to wave a dead chicken in front of my
monitor and spend the bigger part of the day wondering which
incantation I did wrong.

Martijn
On 11/26/08, Ricardo Mayerhofer [EMAIL PROTECTED] wrote:
  

I started to use wicket some time ago, and I'm really enjoying it.
Best
framework ever.
But I've some suggestions.
I think wicket could be better if it had less boiler plate code. This
could
be reduced by using CoC.
Take the FeedBackPanel for example, you always have to add the
component
on
the web page, even if no special handling is requires (which is almost
the
case).
Wicket could have some reserved ids, so if I add a markup with id
feedbackPanel, a feedbackpanel component is automatically added to
that
page.
Another example is SubmitLink component. No special handling required,
but
for wicket sake the developer must add it on the java the page.
--
View this message in context:
http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.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]




--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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



  

--
View this message in context:
http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.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]



  



  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 

Re: continueToOriginalDestination and POST

2008-11-26 Thread Jonas
I found a JIRA issue was filed for this a while back:
https://issues.apache.org/jira/browse/WICKET-1703

...but it hasn't been addressed yet...

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