date:20081126


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  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: continueToOriginalDestination and POST

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  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: [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
> >
> >
> >
> >  org.apache.maven.plugins
> >  maven-jar-plugin
> >  
> >
> >  
> >  ${project.name}
> >
> >  ${project.version}
> >  ${project.name
> }
> >  ${project.version} ${buildNumber} -
> ${
> > user.name}
> >  ${buildNumber}
> >  ${scm.url}
> >  
> >
> >  
> >
> >
> >
> >
> > 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/
>

Re: Wicket and CoC


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 '

Re: Wicket and CoC

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

Re: Wicket and CoC


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

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

Re: Using CompoundPropertyModel with FormComponentPanel


FYI, you are awesome.

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


igor.vaynberg wrote:
> 
> then just"model.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: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

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
>
>
>
>  org.apache.maven.plugins
>  maven-jar-plugin
>  
>
>  
>  ${project.name}
>
>  ${project.version}
>  ${project.name}
>  ${project.version} ${buildNumber} - ${
> user.name}
>  ${buildNumber}
>  ${scm.url}
>  
>
>  
>
>
>
>
> 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/
>
>

Re: Using CompoundPropertyModel with FormComponentPanel

then just"model.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 TextField("editor", new PropertyModel(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: Wicket and CoC


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 PRO

Re: Wicket Session grows too big real fast


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


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

Re: Using CompoundPropertyModel with FormComponentPanel


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

editor = new TextField("editor", new PropertyModel(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

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

RES: Wicket and CoC

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

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]

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



  org.apache.maven.plugins
  maven-jar-plugin
  

  
  ${project.name}Title>
  ${project.version}Specification-Version>
  ${project.name}Title>
  ${project.version} $ 
{buildNumber} - ${user.name}

  ${buildNumber}
  ${scm.url}
  

  



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]

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

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

Re: Wicket and CoC

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: Wicket and CoC

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


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


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: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

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: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

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: 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: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

>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: [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: Wicket and CoC

-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: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

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: continueToOriginalDestination and POST

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

Wicket and CoC


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: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets


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

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

> 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: continueToOriginalDestination and POST

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  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: 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=7220243&ver=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.

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]

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

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 w

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: Using CompoundPropertyModel with FormComponentPanel

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 TextField editor;
> private Fragment componentFragment;
>
> public class LabelledTextField extends FormComponentPanel {
>
>public LabelledTextField(String id) {
>super(id);
>
>componentFragment = new Fragment(COMPONENT_ID, "textField", this);
>editor = new TextField("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: 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 EntityForm {
>
> private CalendarToDateModel modelStartDate;
> private CalendarToDateModel modelEndDate;
>
> public RankingForm( IModel model, Component dataTable ) {
> super( model, dataTable );
> add( new TextField( "name" ) );
> modelStartDate = new CalendarToDateModel( new
> PropertyModel( model, "startDate" ) );
> add( new DateTextField( "startDate", modelStartDate, new
> StyleDateConverter( "SM", false ) ) );
> modelEndDate = new CalendarToDateModel( new
> PropertyModel( model, "endDate" ) );
> add( new DateTimeField( "endDate", modelEndDate ) );
> add( new TextField( "scoreRight" ) );
> add( new TextField( "scoreWrong" ) );
> add( new TextField( "scoreLimit" ) );
> }
>
> @Override
> public MarkupContainer setDefaultModel( IModel model ) {
> modelStartDate.setDefaultModel( new PropertyModel(
> model, "startDate" ) );
> modelEndDate.setDefaultModel( new PropertyModel(
> model, "endDate" ) );
> return super.setDefaultModel( model );
> }
> ...
>
> HTML:
> 
> Criar/Editar Ranking
> Feedback
> Panel
> Nome:  type="text" size="20"/>
> Data/Hora Início:  type="text" wicket:id="startDate"/>
> Data/Hora Fim:  wicket:id="endDate"/>
> Pontos para Acerto:  wicket:id="scoreRight" type="text" size="10"/>
> Pontos para Erro:  wicket:id="scoreWrong" type="text" size="10"/>
> Limite de Pontos:  wicket:id="scoreLimit" type="text" size="10"/>
> ...
>
>
> 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 IModel and takes an IModel 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: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

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

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

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 conte

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]

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

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

Thanks Matej,

I just noticed org.apache.wicket.markup.repeater.AbstractPageableView
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 se

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

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

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

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

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

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 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
> >
> > 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: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

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: [discuss] Organizing Wicket Stuff / Regular Release Schedule?

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: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

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

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

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

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 comm

Re: continueToOriginalDestination and POST

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  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: AutoCompleteTextField - gives a type mismatch error on IE - version wicket-1.4-rc1

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

continueToOriginalDestination and POST

I have a site which requires authentication. I've made it via
@AuthorizeInstantiation.
Works well. But if a bookmarkable page has a  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]

RES: Wicket Session grows too big real fast

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]

RES: Wicket Session grows too big real fast

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

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

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

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: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

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

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

Wicket Sesion Size - wiki page


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]

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

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

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: 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: Wicket Session grows too big real fast

2008-11-26 Thread Piller Sébastien

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 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: 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 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: Wicket Session grows too big real fast

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

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: AutoCompleteTextField - gives a type mismatch error on IE - version wicket-1.4-rc1

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

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]

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

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]

Re: triggering post of a form, from client side

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: Using CompoundPropertyModel with FormComponentPanel

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?

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

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 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 TextField editor;
private Fragment componentFragment;

public class LabelledTextField extends FormComponentPanel {

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

componentFragment = new Fragment(COMPONENT_ID, "textField", this);
editor = new TextField("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]

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


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]

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: Wicket Session grows too big real fast

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: Wicket Session grows too big real fast

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: Wicket Session grows too big real fast

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

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]

Re: Wicket Session grows too big real fast

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