Re: Page Design Question

[Vladimir K]

Wiket provides PropertyModel class to map to values accessible via
expressions.
You always can write your own models. For instance you can employ Spring
property expressions if you'd like map on collection projection.
You can yield values using great Google collections framework.


Steven Haines wrote:
> 
> First, thanks for your help yesterday with the form id question,
> setMarkupId() solved my problem.
> 
> I have a generic page design question for you: how do you handle
> situations when your page form does not map easily to your domain objects?
> I can map 90% of the form's fields to my domain object, but there are a
> couple fields from which I derive values on my domain object. I can solve
> this by creating a Java object that maps one-to-one with my form and then
> constructing my domain object(s) from that form object, but is there a
> better way / best practice way of handling this situation?
> 
> Thanks for your insight!
> Steve
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Page-Design-Question-tp27918033p27918501.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Wicket in the industry

[Vladimir K]

Look the site has raw wicket urls :)


ananthakumaran wrote:
> 
> http://www.breakitdownblog.com/apache-wicket-powers-mobile-walmart-com/
> 
> On Mon, Mar 15, 2010 at 1:50 PM, Mynhardt Vlok 
> wrote:
> 
>> Hey community
>>
>> I'm testing / using wicket at the moment and have to convince my company
>> to
>> use the framework.
>> I really enjoy wicket and it's ease of use. Thing is my company has asked
>> me
>> two valid questions
>> which I hope the community can answer.
>>
>> 1. How is wicket's stress load? For example could you use the framework
>> for
>> example as an interface to a banking system
>>that handles hundreds of requests at the same time?
>>
>> 2. And i think this question relates to the first one, is wicket being
>> adopted by big businesses? Do they use it for their
>>web interfaces?
>>
>> If anyone can answer these questions I would appreciate it as I would
>> like
>> to convince them to use this framework.
>>
> 
> 
> 
> -- 
> 
> Anantha Kumaran(http://ananthakumaran.github.com)
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Wicket-in-the-industry-tp27901382p27915504.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: wiQuery components with server side state - live demo

[Vladimir K]

Looks great!

One thing is missing - the components don't restore their state on refresh.
I believe cookie, window name or dom storage can be used to keep the
position and settings of components that are available for
dragging/re-arrangement.


Roman Ilin wrote:
> 
> Great, ready for use components.
> 
> 
> 
> On Tue, Mar 2, 2010 at 5:58 PM, Cemal A Bayramoglu 
> wrote:
>> We've been building a few wiQuery components [0], for clients' and
>> internal projects. These wiQuery components typically maintain some of
>> their state server-side, in the spirit of standard Wicket components.
>>
>> Here's a simple demo [1] to show some of them in action.
>>
>> Look carefully and you'll find lots of stuff to click on [2]. We could
>> plan to open up the ones we may [3] if they look useful to you or
>> you'd like to get involved with design/development/testing.
>>
>> Regards - Cemal
>> jWeekend
>> OO & Java Technologies, Wicket
>> Consulting, Development, Training
>> http://jWeekend.com
>>
>> [0] includes components based on sortable "portlet", jqGrid/Tree,
>> jGrowl, jQuery UI: Accordian, Dialog, Tabs all integrated with Wicket
>> using wiQuery (http://code.google.com/p/wiquery/)
>> [1] http://labs.jWeekend.com/public/
>> [2] We'd naturally prefer if you didn't zap _all_ the records from our
>> toy database! Yes, we know some of you will take this as an invitation
>> to have a go!
>> [3] No promises on dates just now, but it is something we'd like to do
>> soon.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/wiQuery-components-with-server-side-state---live-demo-tp27758298p27762474.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Shared resources with parameters?

[Vladimir K]

For now I can't benefit from 304 Not Modified when shared parameterized
resource is mounted with custom mount path (say /databaseimage/ in contrary
to /resources/) and backed by database.
I mean it is not easy to benefit from just implementing
IResourceStream.lastModifiedTime(). It is due WicketFilter checks only
/resource for not modification. The same about stateless pages (that for
instance hosts the db images, which "not modification" status depends
completely on image timestamp).

I believe Igor is right about IResourceStream. Page and Shared Resource both
are resources. And handling them polimorfly would simplify things.

I look forward for the new URL handling technology. I hope it will happen
within 1.5. 


igor.vaynberg wrote:
> 
> well, these are all the questions we would have to answer when we are
> looking into this in detail. i dont have the answers right now, im
> just stating what i would like to see happen. i think the entire
> resource api has become very very bloated and can be simplified.
> 
> -igor
> 
> 
> On Tue, Mar 25, 2008 at 12:43 PM, Johan Compagner 
> wrote:
>> kill IResourceStream looks doable
>>  But also resource?
>>
>>  Where does a ResourceReference then point to?
>>  How do we name the byte[] or streams?
>>
>>  johan
>>
>>
>>  On Tue, Mar 25, 2008 at 7:45 PM, Igor Vaynberg 
>>
>>
>> wrote:
>>
>>  > well, im saying get rid of Resource/ResourceStream entirely. we dont
>>  > need that abstraction, we can just add whatever is missing to resource
>>  > target. actually that way you can also implement page caching
>>  > easily...maybe...
>>  >
>>  > anyways, irequesttarget.getlastmodified(pageparameters) can alleviate
>>  > reliance on the request cycle
>>  >
>>  > -igor
>>  >
>>  >
>>  > On Tue, Mar 25, 2008 at 11:38 AM, Johan Compagner
>> 
>>  > wrote:
>>  > > On Tue, Mar 25, 2008 at 6:46 PM, Igor Vaynberg
>> 
>>  > >  wrote:
>>  > >
>>  > >
>>  > >  > the whole resource thing is soo bloated. something we should
>>  > >  > simplify in 1.5. im all for getting rid of it entirely. we
>> already
>>  > >  > have a nice interface for streams and that is called
>> IRequestTarget,
>>  > >
>>  > >
>>  > >  we already have that:
>>  > >
>>  > >  SharedResourceRequestTarget -> ResourceStreamRequestTarget
>>  > >
>>  > >
>>  > >
>>  > >
>>  > >
>>  > >  >
>>  > >  > just need to add a lastmodifiedtime() to it and we are done :)
>> and it
>>  > >  > also gets rid of the inputstream<->outputstream inconsistency.
>> why
>>  > >  > should a resource provide an inputstream and us copy it when the
>>  > >  > resource can just dump it into the response directly...
>>  > >
>>  > >
>>  > >  we already have that +/- also: IResourceStreamWriter
>>  > >
>>  > >  But i agree it can be simpler
>>  > >
>>  > >  But HEAD request should not go into the complete wicket cycle
>>  > >  Those should be fast as possible. because head request are i think
>> the
>>  > >  happening the most of all the request.
>>  > >
>>  > >  johan
>>  > >
>>  > >
>>  > >
>>  > >
>>  > >
>>  > >  >
>>  > >  >
>>  > >  > -igor
>>  > >  >
>>  > >  >
>>  > >  > On Tue, Mar 25, 2008 at 10:33 AM, Johan Compagner <
>>  > jcompag...@gmail.com>
>>  > >  > wrote:
>>  > >  > > no but the params could contain a filename
>>  > >  > >  and against that you check the last modified time stamp also
>> in
>>  > the DB
>>  > >  > >
>>  > >  > >  just also for performance, if we call:
>>  > >  > >  public abstract IResourceStream getResourceStream();
>>  > >  > >
>>  > >  > >  then dont already get all the data.
>>  > >  > >  Because that call can also just be used for lastModified()
>> check.
>>  > >  > >
>>  > >  > >  that should only lazy be done with the
>>  > IResourceStream.getInputStream()
>>  > >  > call
>>  > >  > >
>>  > >  > >  johan
>>  > >  > >
>>  > >  > >
>>  > >  > >  On Tue, Mar 25, 2008 at 5:51 PM, Igor Vaynberg <
>>  > igor.vaynb...@gmail.com
>>  > >  > >
>>  > >  > >
>>  > >  > >
>>  > >  > > wrote:
>>  > >  > >
>>  > >  > >  > well, hopefully you dont instantiate the resource stream if
>> its
>>  > just
>>  > >  > a
>>  > >  > >  > HEAD response...
>>  > >  > >  >
>>  > >  > >  > -igor
>>  > >  > >  >
>>  > >  > >  >
>>  > >  > >  > On Tue, Mar 25, 2008 at 9:47 AM, Johan Compagner <
>>  > >  > jcompag...@gmail.com>
>>  > >  > >  > wrote:
>>  > >  > >  > > no do
>>  > >  > >  > >
>>  > >  > >  > >  resource/this.getParameters()
>>  > >  > >  > >
>>  > >  > >  > >  dont try to get the RequestCylce
>>  > >  > >  > >  if it is a HEAD request (last modified check) it doesn't
>> have
>>  > to
>>  > >  > be
>>  > >  > >  > there..
>>  > >  > >  > >
>>  > >  > >  > >  johan
>>  > >  > >  > >
>>  > >  > >  > >  On Tue, Mar 25, 2008 at 5:44 PM, Igor Vaynberg <
>>  > >  > igor.vaynb...@gmail.com
>>  > >  > >  > >
>>  > >  > >  > >  wrote:
>>  > >  > >  > >
>>  > >  > >  > >
>>  > >  > >  > >
>>  > >  > >  > >  > and inside the resource you do
>>  > >  > >  > >  >
>>  > >  > >  > >  > RequestCycle.get().getRequest().getParameter("foo

Re: Bookmarkable link url is broken in 1.4.6 after ajax update

[Vladimir K]

It seems that problem prepending resource URLs resurrected again.
https://issues.apache.org/jira/browse/WICKET-2491


vineet semwal wrote:
> 
> i have opened the jira issue for the same problem,
> https://issues.apache.org/jira/browse/WICKET-2717
> 
> On Thu, Feb 4, 2010 at 1:07 AM, vineet semwal
> wrote:
> 
>> I noticed the same problem after moving to 1.4.6 ,
>> I am creating a new bookmarkablepagelink on ajax submit ,
>>  current page mounted path is prefixed in my case,
>> i checked it with 1.4.5,it doesn't have that problem.
>>
>> for eg. bookmarkablepagelink created is
>> http://foo/currentpagemountedpath/destinationpagemountedpath
>>
>>
>>
>> On Wed, Feb 3, 2010 at 10:44 PM, Objelean Alex
>> wrote:
>>
>>> The wicket-1.4.6 release contains a fix for WICKET-2312, which is a
>>> great
>>> thing. But apparently it breaks Bookmarkable link url in situation when
>>> it
>>> is updated by ajax. I'm not sure if this description is enough for fast
>>> reproduction, but I will try to add a quickstart asap and will open a
>>> JIRA
>>> issue.
>>>
>>> This issue is pretty critical. I cannot migrate the application to
>>> wicket-1.4.6 because of it.
>>>
>>> Thank you!
>>>
>>
>>
>>
>> --
>> regards,
>> Vineet Semwal
>>
> 
> 
> 
> -- 
> regards,
> Vineet Semwal
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Bookmarkable-link-url-is-broken-in-1.4.6-after-ajax-update-tp27439970p27453809.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Wicket Release Plans for 1.5

[Vladimir K]

The best would be short release cycle and very long support cycle. The latter
is more important.


igor.vaynberg wrote:
> 
> do you guys want a release cycle that will take a year?
> 
> the auto-detaching models are perfectly possible now by implementing a
> IDetachListener and detaching all fields that implement IDetachable
> via reflection.
> 
> -igor
> 
> 
> On Sun, Nov 1, 2009 at 3:05 AM, Vladimir K  wrote:
>>
>> what about promiced auto-detaching models? may we expect it in 1.5?
>>
>>
>> igor.vaynberg wrote:
>>>
>>> possibly. i think i would like this release to be as small as
>>> possible, centered around the new url stuff. once that is in release
>>> 1.5 and put the new ajax support from ng into 1.6.
>>>
>>> trying to release more and more often instead of taking over a year
>>> and a half like we did with 1.4.0
>>>
>>> -igor
>>>
>>> On Fri, Oct 30, 2009 at 5:10 AM, Richard Allen
>>>  wrote:
>>>> Is the Wicket Ajax Next Generation work going into 1.5?
>>>>
>>>> Also, is there plans for an event bus, sort of like what you see in
>>>> Jonathan
>>>> Locke's 26 wicket tricks source code? I've seen some really nice use of
>>>> event bus in GWT that I think Wicket could benefit from.
>>>>
>>>> -Richard
>>>>
>>>>
>>>> On Fri, Oct 30, 2009 at 4:43 AM, Dave B  wrote:
>>>>
>>>>> > I'm still eager to make WicketTester a first class citizen.
>>>>>
>>>>> I'm keen on this too -- is there a 'voting' mechanism in the bug
>>>>> tracker for this sort of thing?
>>>>>
>>>>> Cheers,
>>>>> Dave
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Oct 30, 2009 at 7:27 PM, Martijn Dashorst
>>>>>  wrote:
>>>>> > I'm still eager to make WicketTester a first class citizen.
>>>>> >
>>>>> > Martijn
>>>>> >
>>>>> > On Thu, Oct 29, 2009 at 7:01 PM, dtoffe  wrote:
>>>>> >>
>>>>> >>    Thanks for your answer,
>>>>> >>
>>>>> >> Daniel
>>>>> >>
>>>>> >>
>>>>> >> igor.vaynberg wrote:
>>>>> >>>
>>>>> >>> the focus of this release is to rewrite url and page handling. the
>>>>> >>> focus is on flexibility and pluggability as well as simplification
>>>>> of
>>>>> >>> use to the end user.
>>>>> >>>
>>>>> >>> the other major feature is the markupfragment implementation,
>>>>> which
>>>>> >>> will allow users access to the markup the component is attached
>>>>> to,
>>>>> >>> possibly, at a time earlier then render time.
>>>>> >>>
>>>>> >>> other then that there will probably be smaller features that will
>>>>> not
>>>>> >>> go into 1.4.x because they require an api break.
>>>>> >>>
>>>>> >>> -igor
>>>>> >>>
>>>>> >>> On Thu, Oct 29, 2009 at 10:38 AM, dtoffe 
>>>>> wrote:
>>>>> >>>>
>>>>> >>>>    Besides, it would be very interesting to know what changes and
>>>>> new
>>>>> >>>> features are planned.
>>>>> >>>>
>>>>> >>>> Cheers,
>>>>> >>>>
>>>>> >>>> Daniel
>>>>> >>>>
>>>>> >>>
>>>>> >>>
>>>>> >>
>>>>> >> --
>>>>> >> View this message in context:
>>>>> http://www.nabble.com/Wicket-Release-Plans-for-1.5-tp26115807p26117927.html
>>>>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> -
>>>>> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> >> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>> >>
>>>>&

Re: Wicket Release Plans for 1.5

[Vladimir K]

what about promiced auto-detaching models? may we expect it in 1.5?


igor.vaynberg wrote:
> 
> possibly. i think i would like this release to be as small as
> possible, centered around the new url stuff. once that is in release
> 1.5 and put the new ajax support from ng into 1.6.
> 
> trying to release more and more often instead of taking over a year
> and a half like we did with 1.4.0
> 
> -igor
> 
> On Fri, Oct 30, 2009 at 5:10 AM, Richard Allen
>  wrote:
>> Is the Wicket Ajax Next Generation work going into 1.5?
>>
>> Also, is there plans for an event bus, sort of like what you see in
>> Jonathan
>> Locke's 26 wicket tricks source code? I've seen some really nice use of
>> event bus in GWT that I think Wicket could benefit from.
>>
>> -Richard
>>
>>
>> On Fri, Oct 30, 2009 at 4:43 AM, Dave B  wrote:
>>
>>> > I'm still eager to make WicketTester a first class citizen.
>>>
>>> I'm keen on this too -- is there a 'voting' mechanism in the bug
>>> tracker for this sort of thing?
>>>
>>> Cheers,
>>> Dave
>>>
>>>
>>>
>>> On Fri, Oct 30, 2009 at 7:27 PM, Martijn Dashorst
>>>  wrote:
>>> > I'm still eager to make WicketTester a first class citizen.
>>> >
>>> > Martijn
>>> >
>>> > On Thu, Oct 29, 2009 at 7:01 PM, dtoffe  wrote:
>>> >>
>>> >>    Thanks for your answer,
>>> >>
>>> >> Daniel
>>> >>
>>> >>
>>> >> igor.vaynberg wrote:
>>> >>>
>>> >>> the focus of this release is to rewrite url and page handling. the
>>> >>> focus is on flexibility and pluggability as well as simplification
>>> of
>>> >>> use to the end user.
>>> >>>
>>> >>> the other major feature is the markupfragment implementation, which
>>> >>> will allow users access to the markup the component is attached to,
>>> >>> possibly, at a time earlier then render time.
>>> >>>
>>> >>> other then that there will probably be smaller features that will
>>> not
>>> >>> go into 1.4.x because they require an api break.
>>> >>>
>>> >>> -igor
>>> >>>
>>> >>> On Thu, Oct 29, 2009 at 10:38 AM, dtoffe 
>>> wrote:
>>> 
>>>     Besides, it would be very interesting to know what changes and
>>> new
>>>  features are planned.
>>> 
>>>  Cheers,
>>> 
>>>  Daniel
>>> 
>>> >>>
>>> >>>
>>> >>
>>> >> --
>>> >> View this message in context:
>>> http://www.nabble.com/Wicket-Release-Plans-for-1.5-tp26115807p26117927.html
>>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>>> >>
>>> >>
>>> >> -
>>> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> >> For additional commands, e-mail: users-h...@wicket.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Become a Wicket expert, learn from the best: http://wicketinaction.com
>>> > Apache Wicket 1.4 increases type safety for web applications
>>> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0
>>> >
>>> > -
>>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> > For additional commands, e-mail: users-h...@wicket.apache.org
>>> >
>>> >
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Wicket-Release-Plans-for-1.5-tp26115807p26148878.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Proposal: Fake implementation of AjaxRequestTarget instead of null

[Vladimir K]

I use similar approach and wondering.
... how to make sure that one year later another developer will realize that
there is a helper for her convinience?


svenmeier wrote:
> 
> Hi,
> 
> thinking more about this 'issue' I realized that in these simple cases 
> one can just use a simple helper method:
> 
> onclick(target) {
>   AjaxHelper.addComponent(componentToReRenderOnAjaxRequest);
> }
> 
> It was already discussed how components could automagically be added for 
> re-rendering on each AjaxRequest.
> Such a feature would make a lot of calls to 
> AjaxRequestTarget#addComponent() obsolete.
> 
> Regards
> 
> Sven
> 
> Vladimir K wrote:
>> Although it is possible I wouldn't recommend authoring certainly
>> different UI
>> basing on the asynchronisity of the request. For instance I experience
>> inconvinience when mistakely opening Outlook Web Access in Firefox
>> instead
>> of MS IE and seeing a bit different non-ajaxy UI.
>>
>> All the handlers of fallback components in my code perform the same logic
>> for ajax and non-ajax requests. The only difference is that I have to
>> tell
>> Wicket what components are invalidated due to changes in data model. I
>> find
>> it to be a good design style. That sort of information is just a garbage
>> for
>> the current Wicket rendering algorithm but thing could be different in
>> the
>> future if you decided to optimize the re-rendering process.
>>
>> From the other hand I would prefer to just call RequestTarget.isAjax() to
>> distinguish what interface I should present to the user in case when it
>> is
>> reasonable different. Checking whether the object is null is much
>> dangerous
>> and non-self-descriptive. IMHO it is no-no design practice.
>>
>> Since the number of fallback components is pretty small it is not
>> difficult
>> to derive from them some project-local components and wrap event handling
>> in
>> a manner I proposed to guard from NPE. But intention was to improve the
>> Wicket API not only for that particular case.
>>
>>
>> igor.vaynberg wrote:
>>   
>>> On Sat, Oct 24, 2009 at 7:18 AM, Sven Meier  wrote:
>>>
>>> 
>>>> I don't think he meant a *complete* no-op request target, just the
>>>> method
>>>> addComponent() would be a no-op. The fake request target will rerender
>>>> the
>>>> complete page as any other standard request would do.
>>>>   
>>> this is not possible. all public contracts of the request target have
>>> to be properly implemented. eg if a component was added it should be
>>> returned by getcomponents(), also any registered listeners have to be
>>> notified, etc.
>>>
>>> i really dont understand the point of this change. if you have a fake
>>> ajaxrequesttarget then the code for a fallback is essentially a noop,
>>> so your app is broken in fallback.
>>>
>>> most of the code i have written that utilizes the fallback
>>> functionality looks like this:
>>>
>>> onclick(target) {
>>>   if (target==null) {
>>> setresponsepage(new editpage(...));
>>>   } else {
>>> setupInp+laceEditPanel();
>>>   }
>>> }
>>>
>>> the workflows are divergent.
>>>
>>> -igor
>>>
>>> 
>>>> BTW why don't we get rid of all those AjaxFallback... components and
>>>> just
>>>> let *all* Ajax... components support use of a standard HTML request as
>>>> fallback?
>>>>
>>>> Regards
>>>>
>>>> Sven
>>>>
>>>> Martin Grigorov wrote:
>>>>   
>>>>> I think he meant wasting CPU cycles for constructing your components
>>>>> which will be added to no-op ajaxrequesttarget
>>>>>
>>>>> then you'll have to make check like "if (target instanceOf
>>>>> NullAjaxRequestTarget) {return;}" which is not better than before
>>>>>
>>>>> El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió:
>>>>>
>>>>> 
>>>>>> I think it absolutely makes sense (for a future release of wicket).
>>>>>> having a NullObject instance of AjaxRequestTarget would not waste a
>>>>>> lot
>>>>>> of cpu cycles at all, at least not how i use it. the only thing i do
>>>>>> with
>>>>>> the

Re: Proposal: Fake implementation of AjaxRequestTarget instead of null

[Vladimir K]

Consistent UI is very important for the user, isn't it? It has nothing in
common with my "liking".

My proposal is about how to make the Wicket user life simpler. Not only by
omitting coding null-checks. It is about bugs related to forgotten
null-checks. And it is about consistent API.

I strive to limit the places where use of instanceof operator is by-design.


igor.vaynberg wrote:
> 
> On Sat, Oct 24, 2009 at 5:23 PM, Vladimir K  wrote:
>>
>> Although it is possible I wouldn't recommend authoring certainly
>> different UI
>> basing on the asynchronisity of the request. For instance I experience
>> inconvinience when mistakely opening Outlook Web Access in Firefox
>> instead
>> of MS IE and seeing a bit different non-ajaxy UI.
> 
> just because something is not to your "liking" doesnt mean it should
> not be possible, so modify your proposal accordingly.
> 
>> From the other hand I would prefer to just call RequestTarget.isAjax() to
>> distinguish what interface I should present to the user in case when it
>> is
>> reasonable different. Checking whether the object is null is much
>> dangerous
>> and non-self-descriptive. IMHO it is no-no design practice.
> 
> in that case it should just be an onclick() inside which you can do:
> 
> if (requestcycle.getrequesttarget() instanceof ajaxrequesttarget) {
>  
> }
> 
> -igor
> 
> 
> 
>>
>> Since the number of fallback components is pretty small it is not
>> difficult
>> to derive from them some project-local components and wrap event handling
>> in
>> a manner I proposed to guard from NPE. But intention was to improve the
>> Wicket API not only for that particular case.
>>
>>
>> igor.vaynberg wrote:
>>>
>>> On Sat, Oct 24, 2009 at 7:18 AM, Sven Meier  wrote:
>>>
>>>> I don't think he meant a *complete* no-op request target, just the
>>>> method
>>>> addComponent() would be a no-op. The fake request target will rerender
>>>> the
>>>> complete page as any other standard request would do.
>>>
>>> this is not possible. all public contracts of the request target have
>>> to be properly implemented. eg if a component was added it should be
>>> returned by getcomponents(), also any registered listeners have to be
>>> notified, etc.
>>>
>>> i really dont understand the point of this change. if you have a fake
>>> ajaxrequesttarget then the code for a fallback is essentially a noop,
>>> so your app is broken in fallback.
>>>
>>> most of the code i have written that utilizes the fallback
>>> functionality looks like this:
>>>
>>> onclick(target) {
>>>   if (target==null) {
>>>     setresponsepage(new editpage(...));
>>>   } else {
>>>     setupInp+laceEditPanel();
>>>   }
>>> }
>>>
>>> the workflows are divergent.
>>>
>>> -igor
>>>
>>>>
>>>> BTW why don't we get rid of all those AjaxFallback... components and
>>>> just
>>>> let *all* Ajax... components support use of a standard HTML request as
>>>> fallback?
>>>>
>>>> Regards
>>>>
>>>> Sven
>>>>
>>>> Martin Grigorov wrote:
>>>>>
>>>>> I think he meant wasting CPU cycles for constructing your components
>>>>> which will be added to no-op ajaxrequesttarget
>>>>>
>>>>> then you'll have to make check like "if (target instanceOf
>>>>> NullAjaxRequestTarget) {return;}" which is not better than before
>>>>>
>>>>> El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió:
>>>>>
>>>>>>
>>>>>> I think it absolutely makes sense (for a future release of wicket).
>>>>>> having a NullObject instance of AjaxRequestTarget would not waste a
>>>>>> lot
>>>>>> of cpu cycles at all, at least not how i use it. the only thing i do
>>>>>> with
>>>>>> the object is call .addComponent() and then refering a
>>>>>> already-initialized
>>>>>> variable.
>>>>>>
>>>>>> how likely is it that the object is in fact null? its <5% of users
>>>>>> who
>>>>>> have javascript disabled. so this would affect only a small amount of
>>>>>> requests.
>>>>>>
>>>>

Re: Proposal: Fake implementation of AjaxRequestTarget instead of null

[Vladimir K]

Although it is possible I wouldn't recommend authoring certainly different UI
basing on the asynchronisity of the request. For instance I experience
inconvinience when mistakely opening Outlook Web Access in Firefox instead
of MS IE and seeing a bit different non-ajaxy UI.

All the handlers of fallback components in my code perform the same logic
for ajax and non-ajax requests. The only difference is that I have to tell
Wicket what components are invalidated due to changes in data model. I find
it to be a good design style. That sort of information is just a garbage for
the current Wicket rendering algorithm but thing could be different in the
future if you decided to optimize the re-rendering process.

>From the other hand I would prefer to just call RequestTarget.isAjax() to
distinguish what interface I should present to the user in case when it is
reasonable different. Checking whether the object is null is much dangerous
and non-self-descriptive. IMHO it is no-no design practice.

Since the number of fallback components is pretty small it is not difficult
to derive from them some project-local components and wrap event handling in
a manner I proposed to guard from NPE. But intention was to improve the
Wicket API not only for that particular case.


igor.vaynberg wrote:
> 
> On Sat, Oct 24, 2009 at 7:18 AM, Sven Meier  wrote:
> 
>> I don't think he meant a *complete* no-op request target, just the method
>> addComponent() would be a no-op. The fake request target will rerender
>> the
>> complete page as any other standard request would do.
> 
> this is not possible. all public contracts of the request target have
> to be properly implemented. eg if a component was added it should be
> returned by getcomponents(), also any registered listeners have to be
> notified, etc.
> 
> i really dont understand the point of this change. if you have a fake
> ajaxrequesttarget then the code for a fallback is essentially a noop,
> so your app is broken in fallback.
> 
> most of the code i have written that utilizes the fallback
> functionality looks like this:
> 
> onclick(target) {
>   if (target==null) {
> setresponsepage(new editpage(...));
>   } else {
> setupInp+laceEditPanel();
>   }
> }
> 
> the workflows are divergent.
> 
> -igor
> 
>>
>> BTW why don't we get rid of all those AjaxFallback... components and just
>> let *all* Ajax... components support use of a standard HTML request as
>> fallback?
>>
>> Regards
>>
>> Sven
>>
>> Martin Grigorov wrote:
>>>
>>> I think he meant wasting CPU cycles for constructing your components
>>> which will be added to no-op ajaxrequesttarget
>>>
>>> then you'll have to make check like "if (target instanceOf
>>> NullAjaxRequestTarget) {return;}" which is not better than before
>>>
>>> El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió:
>>>

 I think it absolutely makes sense (for a future release of wicket).
 having a NullObject instance of AjaxRequestTarget would not waste a lot
 of cpu cycles at all, at least not how i use it. the only thing i do
 with
 the object is call .addComponent() and then refering a
 already-initialized
 variable.

 how likely is it that the object is in fact null? its <5% of users who
 have javascript disabled. so this would affect only a small amount of
 requests.

 from a jvm perspective calling methods with empty bodys very often is
 not
 something expensive. they will get inlined by the hotspot compiler and
 be
 effectively free. (i am not 100% sure if this also applys to
 polymorphism
 chains.)

 from a "clean-code" prespective it is often considered a code smell to
 have a lot of null checks.
 in your example providing a FakeDatabaseConnection that throws an
 UnsrupportedOperationException("you have no database!") is better than
 seeing a null pointer exception.


>
> Sounds weird.
>
> Why should my component burn cpu cycles to feed a fake ajax target
> which
> does nothing at all?
>
> I would prefer some null checks in that case.
>
> Would you also provide a FakeDatabaseConnection in case you
> application
> does not support databases? :-)
>
>
> Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk:
>
>
>>
>> I believe all those null-checks of request target can be omited in
>> user
>> code
>> if fallback components would provide fake implementation of
>> AjaxRequestTarget instead of passing null.
>>
>> Does it make sense?
>>

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



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

Re: ProgressBar demo doesn't work for firefox 3.5.3

[Vladimir K]

The UploadProgressBar does not work for me.
-- 
View this message in context: 
http://www.nabble.com/ProgressBar-demo-doesn%27t-work-for-firefox-3.5.3-tp25717607p25729075.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Complicated workflows

[Vladimir K]

I tried JBoss JBPM and it worked for complex compound workflows. It also had
a eclipse designer plugin that could save the workflow image and provided a
class that visualised the current workflow state.

It had persistence module that was based on Hibernate. I had just to
implement simple UI to present a user with workflows and tasks.

I believe user can stay unaware about how complex is the workflow and
whether it is compound.


Phil Housley wrote:
> 
> Hello list,
> 
> I'm currently working on some ideas for building apps with fairly
> complex workflows.  My aim is to find a nice pattern/framework for
> building apps where each unit of work involves many panels, several
> forms, lots of decisions and so on.  In particular I'm aiming at apps
> where you need to be very confident about exactly what is happening,
> so very strict control of actions, being careful of multiple
> renderings of a page each trying to change the server data, and so on.
>  Also, I'm wondering about some options for declarative building of
> workflows out of existing tasks.
> 
> My current design involves running from a special page, which
> maintains a stack of tasks.  One type of task is a Workflow, which can
> be configured to automatically spawn subtasks as required, based on
> the result of previous tasks.  Another type of task is based on a
> panel, and is able to cause itself to be rendered.  The stack
> processor makes sure that each task is invoked at the right time, that
> a task can render if it is at the top of the stack, that only the top
> of the stack can be invoked from a form and so on.
> 
> This is working ok for some silly demo cases, but there are various
> issues.  For example, any task that is not also a component cannot
> access dependency injection, or set error messages and so on.  I'm not
> sure how to get around this at the moment, as I don't want to force
> every task to be a component, when many will likely have no cause to
> ever be rendered.
> 
> So, the reason I'm posting is to ask mainly two things:
> 
> 1) Is this of interest to anyone else?  All the code is my own, so
> I'll open source it if there seems to be some future in it.
> 
> 2) If so, does anyone have any comments on my current design?  Clearly
> there are problems with it, but should I carry on trying to find ways
> to work around them, or does the whole thing sounds like so much
> crack?
> 
> Thanks,
> 
> -- 
> Phil Housley
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

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


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

Re: Wrong path to wicket-event.js resulting in 404 after calling wicket from javascript

[Vladimir K]

I believe the code that causes the problem is

#
@Override
#
protected CharSequence getURL()
#
{
#
return super.getURL() +
String.format("&TB_iframe=true&height=%d&width=%d&modal=false", getHeight(),
getWidth());
#
}

IFAIK wicket encodes URL parameters in a special form. And the last part is
the number of "../" required for prepending the resource urls. In your app
it might be zero so wicket do not generate appropriate "../../.." for your
"app/shop/rozkovec" mount string.


Vit Rozkovec wrote:
> 
> Hallo,
> I came across strange problem I do not know whether it is mine fault or
> wicket's problem.
> 
> On a page, there is a widget, which list news records.
> Each record has an edit and delete link. Edit link opens new dialog in
> jquery's thickbox window, which is practically IFrame.
> 
> The code for page, which holds form and which is displayed in the thickbox
> window:
> http://pastebin.com/m5ca60e78
> 
> The code for a link, which shows the thickbox window with a page in it:
> http://pastebin.com/m6339b3a
> 
> En example usage:
> http://pastebin.com/m768350aa
> here on line 72 when I do:
> target.addComponent(ShopNewsWidgetPanel.this.get("news-container"));
> 
> after ajax refresh of the component, which contains news records, each
> record containing edit link, there is 404 error found in the Ajax debug
> window.
> From firebug console I can find out that if I add a some component (here
> it is edit link, which is held by news-container), which also contains
> AbstractDefaultAjaxBehavior, then upon rendering head of the response,
> there is wrong path to wicket ajax resources:
> 
> Correct path:
> http://localhost:8080/cz.madewithlove/app/resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js
> 
> Wrong path after ajax call:
> http://localhost:8080/cz.madewithlove/app/shop/rozkovec/resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js
> 
> The page is mounted like so:
> mount(new IndexedHybridUrlCodingStrategy("shop", ShopModulePage.class));
> 
> An ajax function, which is called in the page's ajax button onSubmit()
> method:
> 
> function thickbox_window_close(url)
> {
>tb_remove(); //removes thickbox window
> 
>// call url of the behavior, this behavior is attached to the link,
> which opens the page in thickbox window
>var wcall=wicketAjaxGet(url, null, null, function() {return true;});
> 
>return !wcall;
> }
> 
> I could solve it by visiting all components of the parent container except
> behaviors and add them to the ajax request target, but it would be better
> to not bother about it and just add the parent container. Any pointers?
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Wrong-path-to-wicket-event.js-resulting-in-404-after-calling-wicket-from-javascript-tp25678997p25681934.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request

[Vladimir K]

Igor, it seems the 1.4 snapshot in the maven repository still contains 1.5
code.

I built wicket from sources locally. When I tested the project against that
build I found yet another problem. Attempt to submit the form (no matter
what value the default processing flag has) led to response with 404 status.
I realized that it was the UploadProgressBar's progressbar.js resource
reference whose url was obtained using MixedParamHybridUrlCodingStrategy.

I created a demo project and attached it to the following issue:
https://issues.apache.org/jira/browse/WICKET-2491

Please have a look. I suppose the problem caused by request context that
does not countain mounted part of the page so the url to the resource does
not contain the "../../.." part and as the result being applied to the page
with context "/some/some/some" causes 404.


igor.vaynberg wrote:
> 
> the problem is that trunk did not have version numbers updated so it
> was building as 1.4 for a while. this has been fixed so latest
> snapshots should be properly built out of branch.
> 
> -igor
> 
> On Sat, Sep 19, 2009 at 10:50 PM, Vladimir K  wrote:
>>
>> The latest 1.4 snapshot does not define IComponentBorder interface in
>> addition to disappeared form component persistence.
>>
>> Is it supposed that 1.4.2 breaks compatibility with 1.4.1?
>>
>> I see the only way to check the fix in wicket-ajax.js - mix it into
>> wicket
>> 1.4.1 jar.
>>
>>
>>
>> Vladimir K wrote:
>>>
>>> I use 1.4-snapshot from
>>> http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.4-SNAPSHOT/
>>>
>>> Persistence of form components has been removed from 1.4 as well.z
>>>
>>>
>>> martin-g wrote:
>>>>
>>>> You have to use 1.4.x branch.
>>>> trunk is for 1.5. form persistence is removed only in trunk
>>>>
>>>>
>>>> El vie, 18-09-2009 a las 05:32 -0700, Vladimir K escribió:
>>>>> Igor, thanks for the fix.
>>>>>
>>>>> I tried to compile against 1.4.2-20090916 and obtained two compilation
>>>>> errors. Now FormComponent does not contain method setPersistent() and
>>>>> Page
>>>>> does not contain method removePersistedFormData().
>>>>>
>>>>> What API should be used instead?
>>>>>
>>>>>
>>>>> Vladimir K wrote:
>>>>> >
>>>>> > Igor, could you plan it for 1.4.2?
>>>>> >
>>>>> >
>>>>> > Vladimir K wrote:
>>>>> >>
>>>>> >> done
>>>>> >>
>>>>> >> https://issues.apache.org/jira/browse/WICKET-2463
>>>>> >>
>>>>> >>
>>>>> >> Vladimir K wrote:
>>>>> >>>
>>>>> >>> sure
>>>>> >>>
>>>>> >>>
>>>>> >>> igor.vaynberg wrote:
>>>>> >>>>
>>>>> >>>> i guess create a quickstart and attach it to a jira issue. when i
>>>>> >>>> tested buttons, while developing the feature, it seemed to work
>>>>> fine.
>>>>> >>>>
>>>>> >>>> -igor
>>>>> >>>>
>>>>> >>>> On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K 
>>>>> wrote:
>>>>> >>>>>
>>>>> >>>>> it is attached to the  tag as follows:
>>>>> >>>>>
>>>>> >>>>>                        >>>> >>>>> enctype='multipart/form-data'>
>>>>> >>>>>                                
>>>>> >>>>>                                        >>>> wicket:id="cancelAction"
>>>>> >>>>> type="submit"
>>>>> >>>>> wicket:message="value:command.cancelAction">
>>>>> >>>>>                                
>>>>> >>>>>                        
>>>>> >>>>>
>>>>> >>>>> From my perspective the request is submitted very similar to as
>>>>> I
>>>>> >>>>> remember
>>>>> >>>>> submitting drop downs many years ago
>>>>> >>>>> 
>>>>> >>>>> T

Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request

[Vladimir K]

The latest 1.4 snapshot does not define IComponentBorder interface in
addition to disappeared form component persistence.

Is it supposed that 1.4.2 breaks compatibility with 1.4.1?

I see the only way to check the fix in wicket-ajax.js - mix it into wicket
1.4.1 jar.



Vladimir K wrote:
> 
> I use 1.4-snapshot from
> http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.4-SNAPSHOT/
> 
> Persistence of form components has been removed from 1.4 as well.z
> 
> 
> martin-g wrote:
>> 
>> You have to use 1.4.x branch.
>> trunk is for 1.5. form persistence is removed only in trunk
>> 
>> 
>> El vie, 18-09-2009 a las 05:32 -0700, Vladimir K escribió:
>>> Igor, thanks for the fix.
>>> 
>>> I tried to compile against 1.4.2-20090916 and obtained two compilation
>>> errors. Now FormComponent does not contain method setPersistent() and
>>> Page
>>> does not contain method removePersistedFormData().
>>> 
>>> What API should be used instead?
>>> 
>>> 
>>> Vladimir K wrote:
>>> > 
>>> > Igor, could you plan it for 1.4.2?
>>> > 
>>> > 
>>> > Vladimir K wrote:
>>> >> 
>>> >> done
>>> >> 
>>> >> https://issues.apache.org/jira/browse/WICKET-2463
>>> >> 
>>> >> 
>>> >> Vladimir K wrote:
>>> >>> 
>>> >>> sure
>>> >>> 
>>> >>> 
>>> >>> igor.vaynberg wrote:
>>> >>>> 
>>> >>>> i guess create a quickstart and attach it to a jira issue. when i
>>> >>>> tested buttons, while developing the feature, it seemed to work
>>> fine.
>>> >>>> 
>>> >>>> -igor
>>> >>>> 
>>> >>>> On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K 
>>> wrote:
>>> >>>>>
>>> >>>>> it is attached to the  tag as follows:
>>> >>>>>
>>> >>>>>>> >>>>> enctype='multipart/form-data'>
>>> >>>>>
>>> >>>>>>> wicket:id="cancelAction"
>>> >>>>> type="submit"
>>> >>>>> wicket:message="value:command.cancelAction">
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> From my perspective the request is submitted very similar to as I
>>> >>>>> remember
>>> >>>>> submitting drop downs many years ago
>>> >>>>> 
>>> >>>>> The request parameters contain the name of the form instead of the
>>> >>>>> name of
>>> >>>>> the button.
>>> >>>>>
>>> >>>>>
>>> >>>>> igor.vaynberg wrote:
>>> >>>>>>
>>> >>>>>> this bit of javascript:
>>> >>>>>>
>>> >>>>>> if (submitButton != null) { s += Wicket.Form.encode(submitButton)
>>> +
>>> >>>>>> "=1";
>>> >>>>>> }
>>> >>>>>>
>>> >>>>>> is needed because we do perform a custom form serialization -
>>> really
>>> >>>>>> just constructing the query string - that we submit back to
>>> server
>>> >>>>>> via
>>> >>>>>> ajax. the multipart handling performs a regular post into a
>>> hidden
>>> >>>>>> iframe so the browser performs the serialization - and that
>>> should
>>> >>>>>> include the button. what markup is your button attached to?
>>> >>>>>>
>>> >>>>>> -igor
>>> >>>>>>
>>> >>>>>> On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk
>>> >>>>>> 
>>> >>>>>> wrote:
>>> >>>>>>> I added
>>> AjaxFallbackButton("Cancel").setDefaultFormProcessing(false)
>>> >>>>>>> to
>>> >>>>>>> the
>>> >>>>>>

Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request

[Vladimir K]

I use 1.4-snapshot from
http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.4-SNAPSHOT/


martin-g wrote:
> 
> You have to use 1.4.x branch.
> trunk is for 1.5. form persistence is removed only in trunk
> 
> 
> El vie, 18-09-2009 a las 05:32 -0700, Vladimir K escribió:
>> Igor, thanks for the fix.
>> 
>> I tried to compile against 1.4.2-20090916 and obtained two compilation
>> errors. Now FormComponent does not contain method setPersistent() and
>> Page
>> does not contain method removePersistedFormData().
>> 
>> What API should be used instead?
>> 
>> 
>> Vladimir K wrote:
>> > 
>> > Igor, could you plan it for 1.4.2?
>> > 
>> > 
>> > Vladimir K wrote:
>> >> 
>> >> done
>> >> 
>> >> https://issues.apache.org/jira/browse/WICKET-2463
>> >> 
>> >> 
>> >> Vladimir K wrote:
>> >>> 
>> >>> sure
>> >>> 
>> >>> 
>> >>> igor.vaynberg wrote:
>> >>>> 
>> >>>> i guess create a quickstart and attach it to a jira issue. when i
>> >>>> tested buttons, while developing the feature, it seemed to work
>> fine.
>> >>>> 
>> >>>> -igor
>> >>>> 
>> >>>> On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K 
>> wrote:
>> >>>>>
>> >>>>> it is attached to the  tag as follows:
>> >>>>>
>> >>>>>> >>>>> enctype='multipart/form-data'>
>> >>>>>
>> >>>>>> wicket:id="cancelAction"
>> >>>>> type="submit"
>> >>>>> wicket:message="value:command.cancelAction">
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> From my perspective the request is submitted very similar to as I
>> >>>>> remember
>> >>>>> submitting drop downs many years ago
>> >>>>> 
>> >>>>> The request parameters contain the name of the form instead of the
>> >>>>> name of
>> >>>>> the button.
>> >>>>>
>> >>>>>
>> >>>>> igor.vaynberg wrote:
>> >>>>>>
>> >>>>>> this bit of javascript:
>> >>>>>>
>> >>>>>> if (submitButton != null) { s += Wicket.Form.encode(submitButton)
>> +
>> >>>>>> "=1";
>> >>>>>> }
>> >>>>>>
>> >>>>>> is needed because we do perform a custom form serialization -
>> really
>> >>>>>> just constructing the query string - that we submit back to server
>> >>>>>> via
>> >>>>>> ajax. the multipart handling performs a regular post into a hidden
>> >>>>>> iframe so the browser performs the serialization - and that should
>> >>>>>> include the button. what markup is your button attached to?
>> >>>>>>
>> >>>>>> -igor
>> >>>>>>
>> >>>>>> On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk
>> >>>>>> 
>> >>>>>> wrote:
>> >>>>>>> I added
>> AjaxFallbackButton("Cancel").setDefaultFormProcessing(false)
>> >>>>>>> to
>> >>>>>>> the
>> >>>>>>> multipart form and when it is pressed the form is handled as well
>> as
>> >>>>>>> the
>> >>>>>>> button would have defaultFormProcessing=true.
>> >>>>>>>
>> >>>>>>> It happens because request parameters does not contain the name
>> of
>> >>>>>>> the
>> >>>>>>> submitting button.
>> >>>>>>>
>> >>>>>>> The magic is in the new code in wicket-ajax.js
>> >>>>>>>
>> >>>>>>>// Submits a form using ajax.
>> >>>>>>>// This method serializes a form and sends it as POST body.
>

Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request

[Vladimir K]

Igor, thanks for the fix.

I tried to compile against 1.4.2-20090916 and obtained two compilation
errors. Now FormComponent does not contain method setPersistent() and Page
does not contain method removePersistedFormData().

What API should be used instead?


Vladimir K wrote:
> 
> Igor, could you plan it for 1.4.2?
> 
> 
> Vladimir K wrote:
>> 
>> done
>> 
>> https://issues.apache.org/jira/browse/WICKET-2463
>> 
>> 
>> Vladimir K wrote:
>>> 
>>> sure
>>> 
>>> 
>>> igor.vaynberg wrote:
>>>> 
>>>> i guess create a quickstart and attach it to a jira issue. when i
>>>> tested buttons, while developing the feature, it seemed to work fine.
>>>> 
>>>> -igor
>>>> 
>>>> On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K  wrote:
>>>>>
>>>>> it is attached to the  tag as follows:
>>>>>
>>>>>                        >>>> enctype='multipart/form-data'>
>>>>>                                
>>>>>                                        >>>> type="submit"
>>>>> wicket:message="value:command.cancelAction">
>>>>>                                
>>>>>                        
>>>>>
>>>>> From my perspective the request is submitted very similar to as I
>>>>> remember
>>>>> submitting drop downs many years ago
>>>>> 
>>>>> The request parameters contain the name of the form instead of the
>>>>> name of
>>>>> the button.
>>>>>
>>>>>
>>>>> igor.vaynberg wrote:
>>>>>>
>>>>>> this bit of javascript:
>>>>>>
>>>>>> if (submitButton != null) { s += Wicket.Form.encode(submitButton) +
>>>>>> "=1";
>>>>>> }
>>>>>>
>>>>>> is needed because we do perform a custom form serialization - really
>>>>>> just constructing the query string - that we submit back to server
>>>>>> via
>>>>>> ajax. the multipart handling performs a regular post into a hidden
>>>>>> iframe so the browser performs the serialization - and that should
>>>>>> include the button. what markup is your button attached to?
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk
>>>>>> 
>>>>>> wrote:
>>>>>>> I added AjaxFallbackButton("Cancel").setDefaultFormProcessing(false)
>>>>>>> to
>>>>>>> the
>>>>>>> multipart form and when it is pressed the form is handled as well as
>>>>>>> the
>>>>>>> button would have defaultFormProcessing=true.
>>>>>>>
>>>>>>> It happens because request parameters does not contain the name of
>>>>>>> the
>>>>>>> submitting button.
>>>>>>>
>>>>>>> The magic is in the new code in wicket-ajax.js
>>>>>>>
>>>>>>>    // Submits a form using ajax.
>>>>>>>    // This method serializes a form and sends it as POST body.
>>>>>>>    submitForm: function(form, submitButton) {
>>>>>>>        if (this.handleMultipart(form)) {
>>>>>>>            return true;
>>>>>>>        }
>>>>>>>        var body = function() {
>>>>>>>            var s = Wicket.Form.serialize(form);
>>>>>>>            if (submitButton != null) {
>>>>>>>                s += Wicket.Form.encode(submitButton) + "=1";
>>>>>>>            }
>>>>>>>            return s;
>>>>>>>        }
>>>>>>>        return this.request.post(body);
>>>>>>>    },
>>>>>>>
>>>>>>> I believe the problem is caused by handleMultipart(form) invocation.
>>>>>>> submitForm function accepts submitButton parameter but does not
>>>>>>> passes it
>>>>>>> to
>>>>>>> handleMultipart function.
>>>>>>>
>>>>>>> Igor could you clarify that?
>>>>>>>
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25507890.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request

[Vladimir K]

Igor, could you plan it for 1.4.2?


Vladimir K wrote:
> 
> done
> 
> https://issues.apache.org/jira/browse/WICKET-2463
> 
> 
> Vladimir K wrote:
>> 
>> sure
>> 
>> 
>> igor.vaynberg wrote:
>>> 
>>> i guess create a quickstart and attach it to a jira issue. when i
>>> tested buttons, while developing the feature, it seemed to work fine.
>>> 
>>> -igor
>>> 
>>> On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K  wrote:
>>>>
>>>> it is attached to the  tag as follows:
>>>>
>>>>                        >>> enctype='multipart/form-data'>
>>>>                                
>>>>                                        >>> type="submit"
>>>> wicket:message="value:command.cancelAction">
>>>>                                
>>>>                        
>>>>
>>>> From my perspective the request is submitted very similar to as I
>>>> remember
>>>> submitting drop downs many years ago
>>>> 
>>>> The request parameters contain the name of the form instead of the name
>>>> of
>>>> the button.
>>>>
>>>>
>>>> igor.vaynberg wrote:
>>>>>
>>>>> this bit of javascript:
>>>>>
>>>>> if (submitButton != null) { s += Wicket.Form.encode(submitButton) +
>>>>> "=1";
>>>>> }
>>>>>
>>>>> is needed because we do perform a custom form serialization - really
>>>>> just constructing the query string - that we submit back to server via
>>>>> ajax. the multipart handling performs a regular post into a hidden
>>>>> iframe so the browser performs the serialization - and that should
>>>>> include the button. what markup is your button attached to?
>>>>>
>>>>> -igor
>>>>>
>>>>> On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk 
>>>>> wrote:
>>>>>> I added AjaxFallbackButton("Cancel").setDefaultFormProcessing(false)
>>>>>> to
>>>>>> the
>>>>>> multipart form and when it is pressed the form is handled as well as
>>>>>> the
>>>>>> button would have defaultFormProcessing=true.
>>>>>>
>>>>>> It happens because request parameters does not contain the name of
>>>>>> the
>>>>>> submitting button.
>>>>>>
>>>>>> The magic is in the new code in wicket-ajax.js
>>>>>>
>>>>>>    // Submits a form using ajax.
>>>>>>    // This method serializes a form and sends it as POST body.
>>>>>>    submitForm: function(form, submitButton) {
>>>>>>        if (this.handleMultipart(form)) {
>>>>>>            return true;
>>>>>>        }
>>>>>>        var body = function() {
>>>>>>            var s = Wicket.Form.serialize(form);
>>>>>>            if (submitButton != null) {
>>>>>>                s += Wicket.Form.encode(submitButton) + "=1";
>>>>>>            }
>>>>>>            return s;
>>>>>>        }
>>>>>>        return this.request.post(body);
>>>>>>    },
>>>>>>
>>>>>> I believe the problem is caused by handleMultipart(form) invocation.
>>>>>> submitForm function accepts submitButton parameter but does not
>>>>>> passes it
>>>>>> to
>>>>>> handleMultipart function.
>>>>>>
>>>>>> Igor could you clarify that?
>>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>> 
>>> 
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25463838.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: How to redirect from a ModalWindow

[Vladimir K]

Try adding this one to the page markup


jQuery(document).ready(function(){
if (typeof Wicket != 'undefined' && 
Wicket.Window)
Wicket.Window.unloadConfirmation = 
false;
});



Matthias Keller wrote:
> 
> Hi Peter
> 
> You would be right as long as it wasn't for a ModalWindow.
> When having an open ModalWindow, wicket seems to register an unload 
> javascript event which - when trying to navigate away from the page (be 
> it by following a link, closing the window etc), displays a confirmation 
> message which you have to accept. I need to avoid that message, but the 
> only way to do that probably is by closing that window first so that the 
> javascript event gets unloaded.
> 
> Matt
> 
> Peter Ertl wrote:
>>
>>
>> throw new RestartResponseException(OtherPage.class)
>>
>> window.close() is not needed!
>>
>>
>> Am 10.09.2009 um 12:50 schrieb Matthias Keller:
>>
>>> OtherPage.class
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
> 
> 
>  
> 

-- 
View this message in context: 
http://www.nabble.com/How-to-redirect-from-a-ModalWindow-tp25381117p25411990.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request

[Vladimir K]

done

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


Vladimir K wrote:
> 
> sure
> 
> 
> igor.vaynberg wrote:
>> 
>> i guess create a quickstart and attach it to a jira issue. when i
>> tested buttons, while developing the feature, it seemed to work fine.
>> 
>> -igor
>> 
>> On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K  wrote:
>>>
>>> it is attached to the  tag as follows:
>>>
>>>                        >> enctype='multipart/form-data'>
>>>                                
>>>                                        >> type="submit"
>>> wicket:message="value:command.cancelAction">
>>>                                
>>>                        
>>>
>>> From my perspective the request is submitted very similar to as I
>>> remember
>>> submitting drop downs many years ago
>>> 
>>> The request parameters contain the name of the form instead of the name
>>> of
>>> the button.
>>>
>>>
>>> igor.vaynberg wrote:
>>>>
>>>> this bit of javascript:
>>>>
>>>> if (submitButton != null) { s += Wicket.Form.encode(submitButton) +
>>>> "=1";
>>>> }
>>>>
>>>> is needed because we do perform a custom form serialization - really
>>>> just constructing the query string - that we submit back to server via
>>>> ajax. the multipart handling performs a regular post into a hidden
>>>> iframe so the browser performs the serialization - and that should
>>>> include the button. what markup is your button attached to?
>>>>
>>>> -igor
>>>>
>>>> On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk 
>>>> wrote:
>>>>> I added AjaxFallbackButton("Cancel").setDefaultFormProcessing(false)
>>>>> to
>>>>> the
>>>>> multipart form and when it is pressed the form is handled as well as
>>>>> the
>>>>> button would have defaultFormProcessing=true.
>>>>>
>>>>> It happens because request parameters does not contain the name of the
>>>>> submitting button.
>>>>>
>>>>> The magic is in the new code in wicket-ajax.js
>>>>>
>>>>>    // Submits a form using ajax.
>>>>>    // This method serializes a form and sends it as POST body.
>>>>>    submitForm: function(form, submitButton) {
>>>>>        if (this.handleMultipart(form)) {
>>>>>            return true;
>>>>>        }
>>>>>        var body = function() {
>>>>>            var s = Wicket.Form.serialize(form);
>>>>>            if (submitButton != null) {
>>>>>                s += Wicket.Form.encode(submitButton) + "=1";
>>>>>            }
>>>>>            return s;
>>>>>        }
>>>>>        return this.request.post(body);
>>>>>    },
>>>>>
>>>>> I believe the problem is caused by handleMultipart(form) invocation.
>>>>> submitForm function accepts submitButton parameter but does not passes
>>>>> it
>>>>> to
>>>>> handleMultipart function.
>>>>>
>>>>> Igor could you clarify that?
>>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25397125.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request

[Vladimir K]

sure


igor.vaynberg wrote:
> 
> i guess create a quickstart and attach it to a jira issue. when i
> tested buttons, while developing the feature, it seemed to work fine.
> 
> -igor
> 
> On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K  wrote:
>>
>> it is attached to the  tag as follows:
>>
>>                        > enctype='multipart/form-data'>
>>                                
>>                                        > type="submit"
>> wicket:message="value:command.cancelAction">
>>                                
>>                        
>>
>> From my perspective the request is submitted very similar to as I
>> remember
>> submitting drop downs many years ago
>> 
>> The request parameters contain the name of the form instead of the name
>> of
>> the button.
>>
>>
>> igor.vaynberg wrote:
>>>
>>> this bit of javascript:
>>>
>>> if (submitButton != null) { s += Wicket.Form.encode(submitButton) +
>>> "=1";
>>> }
>>>
>>> is needed because we do perform a custom form serialization - really
>>> just constructing the query string - that we submit back to server via
>>> ajax. the multipart handling performs a regular post into a hidden
>>> iframe so the browser performs the serialization - and that should
>>> include the button. what markup is your button attached to?
>>>
>>> -igor
>>>
>>> On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk 
>>> wrote:
>>>> I added AjaxFallbackButton("Cancel").setDefaultFormProcessing(false) to
>>>> the
>>>> multipart form and when it is pressed the form is handled as well as
>>>> the
>>>> button would have defaultFormProcessing=true.
>>>>
>>>> It happens because request parameters does not contain the name of the
>>>> submitting button.
>>>>
>>>> The magic is in the new code in wicket-ajax.js
>>>>
>>>>    // Submits a form using ajax.
>>>>    // This method serializes a form and sends it as POST body.
>>>>    submitForm: function(form, submitButton) {
>>>>        if (this.handleMultipart(form)) {
>>>>            return true;
>>>>        }
>>>>        var body = function() {
>>>>            var s = Wicket.Form.serialize(form);
>>>>            if (submitButton != null) {
>>>>                s += Wicket.Form.encode(submitButton) + "=1";
>>>>            }
>>>>            return s;
>>>>        }
>>>>        return this.request.post(body);
>>>>    },
>>>>
>>>> I believe the problem is caused by handleMultipart(form) invocation.
>>>> submitForm function accepts submitButton parameter but does not passes
>>>> it
>>>> to
>>>> handleMultipart function.
>>>>
>>>> Igor could you clarify that?
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377634.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request

[Vladimir K]

it is attached to the  tag as follows:







>From my perspective the request is submitted very similar to as I remember
submitting drop downs many years ago

The request parameters contain the name of the form instead of the name of
the button.


igor.vaynberg wrote:
> 
> this bit of javascript:
> 
> if (submitButton != null) { s += Wicket.Form.encode(submitButton) + "=1";
> }
> 
> is needed because we do perform a custom form serialization - really
> just constructing the query string - that we submit back to server via
> ajax. the multipart handling performs a regular post into a hidden
> iframe so the browser performs the serialization - and that should
> include the button. what markup is your button attached to?
> 
> -igor
> 
> On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk 
> wrote:
>> I added AjaxFallbackButton("Cancel").setDefaultFormProcessing(false) to
>> the
>> multipart form and when it is pressed the form is handled as well as the
>> button would have defaultFormProcessing=true.
>>
>> It happens because request parameters does not contain the name of the
>> submitting button.
>>
>> The magic is in the new code in wicket-ajax.js
>>
>>    // Submits a form using ajax.
>>    // This method serializes a form and sends it as POST body.
>>    submitForm: function(form, submitButton) {
>>        if (this.handleMultipart(form)) {
>>            return true;
>>        }
>>        var body = function() {
>>            var s = Wicket.Form.serialize(form);
>>            if (submitButton != null) {
>>                s += Wicket.Form.encode(submitButton) + "=1";
>>            }
>>            return s;
>>        }
>>        return this.request.post(body);
>>    },
>>
>> I believe the problem is caused by handleMultipart(form) invocation.
>> submitForm function accepts submitButton parameter but does not passes it
>> to
>> handleMultipart function.
>>
>> Igor could you clarify that?
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: DataTable with more than one per item

[Vladimir K]

I mean they does not have toolbars that provides user with pagination,
sorting and filtering. One should author her own DataTable class in order to
get extra  in the item's markup.

If Item class was derived from Panel class it would be possible to override
newRowItem() method.
I believe it makes sense to re-design DataTable markup a bit.


igor.vaynberg wrote:
> 
> both dataview and pageablelistview support paging.
> 
> -igor
> 
> On Mon, Aug 10, 2009 at 4:06 PM, Vladimir K wrote:
>>
>> The regular repeater does not support pagination, sorting and filtering
>> out
>> of the box.
>>
>>
>> Erik van Oosten wrote:
>>>
>>> Kariem,
>>>
>>> There is a hint at
>>> http://cwiki.apache.org/WICKET/wickets-xhtml-tags.html#Wicket%27sXHTMLtags-Elementwicket:container
>>>
>>> Regards,
>>>     Erik.
>>>
>>>
>>> Igor Vaynberg wrote:
>>>> no, a datatable doesnt support that. but it is easy enough with your
>>>> own repeater.
>>>>
>>>> -igor
>>>>
>>>>
>>>
>>> --
>>> Erik van Oosten
>>> http://day-to-day-stuff.blogspot.com/
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/DataTable-with-more-than-one-%3Ctr%3E-per-item-tp24900846p24909100.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/DataTable-with-more-than-one-%3Ctr%3E-per-item-tp24900846p24909271.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: DataTable with more than one per item

[Vladimir K]

The regular repeater does not support pagination, sorting and filtering out
of the box.


Erik van Oosten wrote:
> 
> Kariem,
> 
> There is a hint at 
> http://cwiki.apache.org/WICKET/wickets-xhtml-tags.html#Wicket%27sXHTMLtags-Elementwicket:container
> 
> Regards,
> Erik.
> 
> 
> Igor Vaynberg wrote:
>> no, a datatable doesnt support that. but it is easy enough with your
>> own repeater.
>>
>> -igor
>>
>>   
> 
> -- 
> Erik van Oosten
> http://day-to-day-stuff.blogspot.com/
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/DataTable-with-more-than-one-%3Ctr%3E-per-item-tp24900846p24909100.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Twenty Six Wicket Tricks

[Vladimir K]

Personally I would embed YUI splitter and jQuery layout only if their state
could survive page refresh. It does not seem they are capable for now. AFAIK
it is possible to use coockies to save the state of splitter or docked
panel.


Ralf Eichinger wrote:
> 
> 
> I would prefer to see
> - Javascript component integration: especially YUI split, resizable pane
> containing a panel in each pane or another split pane.
> see: http://developer.yahoo.com/yui/examples/resize/grids_resize.html
> 

-- 
View this message in context: 
http://www.nabble.com/Twenty-Six-Wicket-Tricks-tp21214357p24726444.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: reuseitems problems

[Vladimir K]

Hmm ... i can imagine the only case - somewhere resolveObject() method is
called during deserialization.
But I'm afraid your code don't have such a method and the cause is
different.


MartinM wrote:
> 
> I do not know exactly what happens, but if I run the debugger I can
> see thet the page seen by the formcomponents' propertymodels is in a
> different state than the one actually holding the form components.
> 
> I wonder if ajax has something to do with this, because only part of
> the page is refreshed via ajax. Maybe the parent page and the
> refreshed ajax panel remain in different serialization graphs?
> 
> **
> Martin
> 
> 2009/7/28 Vladimir K :
>>
>> trying to undertand what is happening in your case. When the page is
>> serialized the steam contains the whole graph, including the ListView and
>> it's items and the page default model and the ListView items models. When
>> the page is deserialized, the whole graph is restored including page, its
>> model, items and their models. My understanding is that in your case the
>> items models are the old ones that was in the previous version of the
>> page,
>> how could it be? Or I didn't get what you were saying.
>>
>>
>> MartinM wrote:
>>>
>>> Or session store.. anyways, that's not relevant. The important fact is
>>> that the copies are different.
>>>
>>> **
>>> Martin
>>>
>>> 2009/7/28 Martin Makundi :
>>>>> why do you get Page instance 2 on page refresh?
>>>>
>>>> Wicket always deserializes page state from diskstore.. so it is a copy.
>>>>
>>>> **
>>>> Martin
>>>>
>>>>>
>>>>>
>>>>> MartinM wrote:
>>>>>>
>>>>>>> please describe the context. I don
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/reuseitems-problems-tp24702133p24705851.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

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


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

Re: Twenty Six Wicket Tricks

[Vladimir K]

We developed a RAD framework that builds page design dynamically completely
basing on metadata. So there is no any concrete page that I could extract.

I believe it would be more convinient for you and simpler for me to just
have a look at the concrete page without dynamic layout.


Matej Knopp-2 wrote:
> 
> Doesn't really have to be a complete quickstart. Put the pages with
> markup in a zip (without any external references to your daos, etc).
> That should be enough.
> 
> -Matej
> 
> On Tue, Jul 28, 2009 at 11:13 PM, Vladimir K wrote:
>>
>> Ok then. I'm a noob in maven and ... I even don't know how to make a
>> quickstart of this problem for you. I have never done Wicket project from
>> scratch. But I have just found a free "maven by example book" and started
>> to
>> read. I will be back soon :)
>>
>>
>> Matej Knopp-2 wrote:
>>>
>>> This would be then a bug in nested forms support and not in the modal
>>> window itself. If a form inside modal window is submitted only that
>>> form should be processed. I still don't understand what problem
>>> exactly this fixes.
>>>
>>> -Matej
>>>
>>> On Tue, Jul 28, 2009 at 10:04 PM, Vladimir K wrote:
>>>>
>>>> The following class fixes the problem. It is the evidence of mismatch
>>>> I'm
>>>> saying about.
>>>>
>>>> public class ModalWindowForm extends Form {
>>>>        public ModalWindowForm(String id) {
>>>>                super(id);
>>>>        }
>>>>
>>>>       �...@override
>>>>        public Form getRootForm() {
>>>>                Form form = super.getRootForm();
>>>>
>>>>                if ((findParent(ModalWindow.class) != null) &&
>>>> (form.findParent(ModalWindow.class) == null))
>>>>                        return this;
>>>>                else
>>>>                        return form;
>>>>        }
>>>> }
>>>>
>>>> I assume I don't understand something. But anyway I expect following
>>>> the
>>>> least surprise rule.
>>>>
>>>>
>>>>
>>>> Matej Knopp-2 wrote:
>>>>>
>>>>> On Tue, Jul 28, 2009 at 8:31 PM, Vladimir K wrote:
>>>>>>
>>>>>> Jeremy,
>>>>>>
>>>>>> from my perspective ModalWindow is a mix of javascript widget that
>>>>>> works
>>>>>> in
>>>>>> non-wicket mode and an wicket wrapper that bridges js widget with
>>>>>> wicket.
>>>>>> It
>>>>>> is always created at the body level. That's why I said it's a cheat.
>>>>>> Thus
>>>>>> are problems with form submitting when nested forms are used.
>>>>> There is a good reason why the modal window has to be created on body
>>>>> level. That's the only reliable way to have element
>>>>> with absolute position. If you create the DOM structure deeper you are
>>>>> risking that a container has position:relative somewhere which will
>>>>> essentially break it. Welcome to the wonderful world of CSS.
>>>>>
>>>>>> Community
>>>>>> introduced a solution (a wrapping form that is threated as the root)
>>>>>> to
>>>>>> work
>>>>>> around the mismatch of ModalWindow structure. There is an issue
>>>>>> registered
>>>>>> about that. But Matej keeps stating that we should put MW into a
>>>>>> form.
>>>>>> What
>>>>>> says that he is not aware what the problem is. And there are more
>>>>>> problems
>>>>>> caused by the fact that the  element is created by javascript.
>>>>> Is it, really?
>>>>>
>>>>> I've already explained why the DOM structure is created on root level.
>>>>> If you have form component inside modal window, chances are that
>>>>> wicket will (to support nested forms) render it as div. If this
>>>>> happens it is no longer possible to serialize the form when doing an
>>>>> ajax submit. That's why the actual modal window markup contains a real
>>>>> form.
>>>>>
>>>>> And this is why it is necessary to put a modal window inside a form if
>>

Re: Twenty Six Wicket Tricks

[Vladimir K]

Matej Knopp-2 wrote:
> 
> Modal Window is an ajax component. Submitting it with regular submit
> is not supported and it never was.
> 

But I would like to have AjaxFallbackModalWindow that survives page refresh.
Why not author my own if the aims are different? Probably requirements we
have are far from being accepted as common.



> Again, modal window doesn't support regular submits (by design) so if
> you want to do file upload you'll have to use a hidden iframe or some
> other approach like that.
> 

IMO, Iframe is not an approach it is a work around the limitation (made by
design) :)



> I just looked at jquery dialog example. The dialog is declared in
> markup but it is then reparented as top level DOM element. Same thing
> wicket modalwindow does.
> 

What is especial in my case is that the page height is limited by the window
height and contains a srollable div within. Taking into account that the
browsers we support works well with fixed positioning and assuming that the
following excerpt works:



> Fixed positioning is a special case of absolute positioning. For fixed
> elements, the containing block is always taken to be the viewport of the
> browser window.
> 

It seems to be pretty doable. But it needs investigation. I haven't tried
yet.



>>Anyway it is possible to do what the modal.js is doing by Wicket means and
>>don't have a component tree mismatch with DOM.
> 
> Is it really? Mind sharing with me how?
> 

In case if the position:fixed does not help I would subclass a Form and make
it a container of ModalWindows. Then by placing the
modal-window-container-form at the body level I would acquire a new
ModalWindow from the container. Does it make sense?

-- 
View this message in context: 
http://www.nabble.com/Twenty-Six-Wicket-Tricks-tp21214357p24708596.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Twenty Six Wicket Tricks

[Vladimir K]

Ok then. I'm a noob in maven and ... I even don't know how to make a
quickstart of this problem for you. I have never done Wicket project from
scratch. But I have just found a free "maven by example book" and started to
read. I will be back soon :)


Matej Knopp-2 wrote:
> 
> This would be then a bug in nested forms support and not in the modal
> window itself. If a form inside modal window is submitted only that
> form should be processed. I still don't understand what problem
> exactly this fixes.
> 
> -Matej
> 
> On Tue, Jul 28, 2009 at 10:04 PM, Vladimir K wrote:
>>
>> The following class fixes the problem. It is the evidence of mismatch I'm
>> saying about.
>>
>> public class ModalWindowForm extends Form {
>>        public ModalWindowForm(String id) {
>>                super(id);
>>        }
>>
>>       �...@override
>>        public Form getRootForm() {
>>                Form form = super.getRootForm();
>>
>>                if ((findParent(ModalWindow.class) != null) &&
>> (form.findParent(ModalWindow.class) == null))
>>                        return this;
>>                else
>>                        return form;
>>        }
>> }
>>
>> I assume I don't understand something. But anyway I expect following the
>> least surprise rule.
>>
>>
>>
>> Matej Knopp-2 wrote:
>>>
>>> On Tue, Jul 28, 2009 at 8:31 PM, Vladimir K wrote:
>>>>
>>>> Jeremy,
>>>>
>>>> from my perspective ModalWindow is a mix of javascript widget that
>>>> works
>>>> in
>>>> non-wicket mode and an wicket wrapper that bridges js widget with
>>>> wicket.
>>>> It
>>>> is always created at the body level. That's why I said it's a cheat.
>>>> Thus
>>>> are problems with form submitting when nested forms are used.
>>> There is a good reason why the modal window has to be created on body
>>> level. That's the only reliable way to have element
>>> with absolute position. If you create the DOM structure deeper you are
>>> risking that a container has position:relative somewhere which will
>>> essentially break it. Welcome to the wonderful world of CSS.
>>>
>>>> Community
>>>> introduced a solution (a wrapping form that is threated as the root) to
>>>> work
>>>> around the mismatch of ModalWindow structure. There is an issue
>>>> registered
>>>> about that. But Matej keeps stating that we should put MW into a form.
>>>> What
>>>> says that he is not aware what the problem is. And there are more
>>>> problems
>>>> caused by the fact that the  element is created by javascript.
>>> Is it, really?
>>>
>>> I've already explained why the DOM structure is created on root level.
>>> If you have form component inside modal window, chances are that
>>> wicket will (to support nested forms) render it as div. If this
>>> happens it is no longer possible to serialize the form when doing an
>>> ajax submit. That's why the actual modal window markup contains a real
>>> form.
>>>
>>> And this is why it is necessary to put a modal window inside a form if
>>> you want to have form in modal window. What we should have done is to
>>> put a wicket form inside the modal window panel itself (just to force
>>> all forms in modal window content) to be rendered as nested. But for
>>> some reason i thought that a simple mention in javadoc about putting
>>> modal window to form would be sufficient. My bad.
>>>
>>>>
>>>> From the other hand I believe it is possible to write pure Wicket
>>>> component
>>>> that would be as trice as simpler and won't suffer with problems with
>>>> request lifecycle. Probably I'm wrong and it is not worth turning the
>>>> old
>>>> ModalWindow into pure Wicket component due to expensiveness of the
>>>> effort
>>>> that would be spent to remain it compatible.
>>> Would you mind specifying the actual problems with "request
>>> lifecycle"? And how exactly would a "pure wicket modal window" look
>>> like? No javascript?
>>>>
>>>> The same about tree components. The API is very difficult to
>>>> comprehend.
>>>> Component does not work as I expect in dynamic context. But thankfully
>>>> Sven
>&g

Re: Twenty Six Wicket Tricks

[Vladimir K]

The following class fixes the problem. It is the evidence of mismatch I'm
saying about.

public class ModalWindowForm extends Form {
public ModalWindowForm(String id) {
super(id);
}

@Override
public Form getRootForm() {
Form form = super.getRootForm();

if ((findParent(ModalWindow.class) != null) &&
(form.findParent(ModalWindow.class) == null))
return this;
else
return form;
}
}

I assume I don't understand something. But anyway I expect following the
least surprise rule.



Matej Knopp-2 wrote:
> 
> On Tue, Jul 28, 2009 at 8:31 PM, Vladimir K wrote:
>>
>> Jeremy,
>>
>> from my perspective ModalWindow is a mix of javascript widget that works
>> in
>> non-wicket mode and an wicket wrapper that bridges js widget with wicket.
>> It
>> is always created at the body level. That's why I said it's a cheat. Thus
>> are problems with form submitting when nested forms are used.
> There is a good reason why the modal window has to be created on body
> level. That's the only reliable way to have element
> with absolute position. If you create the DOM structure deeper you are
> risking that a container has position:relative somewhere which will
> essentially break it. Welcome to the wonderful world of CSS.
> 
>> Community
>> introduced a solution (a wrapping form that is threated as the root) to
>> work
>> around the mismatch of ModalWindow structure. There is an issue
>> registered
>> about that. But Matej keeps stating that we should put MW into a form.
>> What
>> says that he is not aware what the problem is. And there are more
>> problems
>> caused by the fact that the  element is created by javascript.
> Is it, really?
> 
> I've already explained why the DOM structure is created on root level.
> If you have form component inside modal window, chances are that
> wicket will (to support nested forms) render it as div. If this
> happens it is no longer possible to serialize the form when doing an
> ajax submit. That's why the actual modal window markup contains a real
> form.
> 
> And this is why it is necessary to put a modal window inside a form if
> you want to have form in modal window. What we should have done is to
> put a wicket form inside the modal window panel itself (just to force
> all forms in modal window content) to be rendered as nested. But for
> some reason i thought that a simple mention in javadoc about putting
> modal window to form would be sufficient. My bad.
> 
>>
>> From the other hand I believe it is possible to write pure Wicket
>> component
>> that would be as trice as simpler and won't suffer with problems with
>> request lifecycle. Probably I'm wrong and it is not worth turning the old
>> ModalWindow into pure Wicket component due to expensiveness of the effort
>> that would be spent to remain it compatible.
> Would you mind specifying the actual problems with "request
> lifecycle"? And how exactly would a "pure wicket modal window" look
> like? No javascript?
>>
>> The same about tree components. The API is very difficult to comprehend.
>> Component does not work as I expect in dynamic context. But thankfully
>> Sven
>> implemented different implementation that does what is expect and usable
>> as
>> well as DataTable component. I believe forking and fixing the original
>> component would be much more expensive. After that so many people should
>> start complaining about that to convince core team that there is not just
>> one person who is experiencing problems. It is always difficult to
>> accomplish.
> I would like to have some clarification on this. What is so difficult
> about the Wicket Tree API? (apart from the fact that it uses swing
> TreeModel which seem to be too confusing for some people). What does
> "dynamic" context mean? Assuming you have properly implemented
> TreeModel that fires the proper notifications, wicket tree is capable
> for updating itself on ajax request by only transmitting the changed
> part to the clients. How much more dynamic can you get?
> 
> For next version we will probably ditch swing TreeModel for something
> simpler but we will still need some kind of modal change notification.
> Wicket tree has many objectives, simplicity is only one of them.
> Having simple tree is nice as long as you don't have to refresh the
> entire thing every time you expand a node or add a node child.
> 
> -Matej
>>
>>
>> jthomerson wrote:
>>>
>>&

Re: Twenty Six Wicket Tricks

[Vladimir K]

Matej,

one of the problems is that when ajax submit happens (by pressing ajax
submit button that resides in a form that resides in a ModalWindow that is
put into another form) it contains no data for the components of enclosing
form but the process of handling the submit handles the eclosing form and
the validation fails or the values become empty. (If I remember all the
details correctly - it was 3 months ago)

Another problem happens when you don't use ajax submit but regular one
instead. If I'm not wrong Wicket can't find components of inner form.

In case if some pieces are missed in sandwitch Form>ModalWinwod>Form the
mismatch occurs immediately.

Having no acces to hardcoded form element makes impossible to enhance
ModalWindow as well as to implement just regular upload submit from within
ModalWindow without patching .js file. If you could fix that (preventing
wicket from making it a div) and make the form configurable it would be
great!

Concerning Tree. It is my subjective opinion. It is the API that was
difficult to figure out how to employ to solve my tasks. I find the
difference betwen DataTable and TreeTable APIs to be unnecessary difficulty
to users. At least they are two different things that requires more time to
learn and work with. And if you have a panel where you switch between table
and tree you have to write an abstraction layer. Sven's TableTree just fits
where it should be. I completely added it within 2 hours. TreeTable took 2
days to learn and employ. Once again, I'm subjective here. It was just my
experience. My idea is that diversity is a good thing when the original
component dont meet our needs makes the development more complicated.

I'm aware of CSS positioning model and I have ideas to investigate. Besides
there are a jQuery popup window which example is embedded into enclosing div
and can be freely relocated inside the body.

Anyway it is possible to do what the modal.js is doing by Wicket means and
don't have a component tree mismatch with DOM.


Matej Knopp-2 wrote:
> 
> On Tue, Jul 28, 2009 at 8:31 PM, Vladimir K wrote:
>>
>> Jeremy,
>>
>> from my perspective ModalWindow is a mix of javascript widget that works
>> in
>> non-wicket mode and an wicket wrapper that bridges js widget with wicket.
>> It
>> is always created at the body level. That's why I said it's a cheat. Thus
>> are problems with form submitting when nested forms are used.
> There is a good reason why the modal window has to be created on body
> level. That's the only reliable way to have element
> with absolute position. If you create the DOM structure deeper you are
> risking that a container has position:relative somewhere which will
> essentially break it. Welcome to the wonderful world of CSS.
> 
>> Community
>> introduced a solution (a wrapping form that is threated as the root) to
>> work
>> around the mismatch of ModalWindow structure. There is an issue
>> registered
>> about that. But Matej keeps stating that we should put MW into a form.
>> What
>> says that he is not aware what the problem is. And there are more
>> problems
>> caused by the fact that the  element is created by javascript.
> Is it, really?
> 
> I've already explained why the DOM structure is created on root level.
> If you have form component inside modal window, chances are that
> wicket will (to support nested forms) render it as div. If this
> happens it is no longer possible to serialize the form when doing an
> ajax submit. That's why the actual modal window markup contains a real
> form.
> 
> And this is why it is necessary to put a modal window inside a form if
> you want to have form in modal window. What we should have done is to
> put a wicket form inside the modal window panel itself (just to force
> all forms in modal window content) to be rendered as nested. But for
> some reason i thought that a simple mention in javadoc about putting
> modal window to form would be sufficient. My bad.
> 
>>
>> From the other hand I believe it is possible to write pure Wicket
>> component
>> that would be as trice as simpler and won't suffer with problems with
>> request lifecycle. Probably I'm wrong and it is not worth turning the old
>> ModalWindow into pure Wicket component due to expensiveness of the effort
>> that would be spent to remain it compatible.
> Would you mind specifying the actual problems with "request
> lifecycle"? And how exactly would a "pure wicket modal window" look
> like? No javascript?
>>
>> The same about tree components. The API is very difficult to comprehend.
>> Component does not work as I expect in dynamic context. But thankfully
>> Sven
>>

Re: reuseitems problems

[Vladimir K]

trying to undertand what is happening in your case. When the page is
serialized the steam contains the whole graph, including the ListView and
it's items and the page default model and the ListView items models. When
the page is deserialized, the whole graph is restored including page, its
model, items and their models. My understanding is that in your case the
items models are the old ones that was in the previous version of the page,
how could it be? Or I didn't get what you were saying.


MartinM wrote:
> 
> Or session store.. anyways, that's not relevant. The important fact is
> that the copies are different.
> 
> **
> Martin
> 
> 2009/7/28 Martin Makundi :
>>> why do you get Page instance 2 on page refresh?
>>
>> Wicket always deserializes page state from diskstore.. so it is a copy.
>>
>> **
>> Martin
>>
>>>
>>>
>>> MartinM wrote:

> please describe the context. I don
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

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


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

Re: reuseitems problems

[Vladimir K]

Martin,

why do you get Page instance 2 on page refresh?


MartinM wrote:
> 
>> please describe the context. I don't see how the process of serialization
>> makes the instance of the object obsolete.
> 
> 1. Page instantiation. Page instance 1 {manipulating target data 1},
> formComponent instance 1->target data instance 1.
> 2. Ajax request or similar onto page.
> 3. Page refresh (deserialized from diskstore). Page instance 2
> {manipulating target data instance 2}, reused formComponent instance
> 1->target data instance 1.
> 
> So in stage 3 the page is manipulating target data instance 2 while
> the reused form components still manipulate target data instance 1.
> 
> What this means? It means that  for example if you Submit form, the
> values will be updated onto target data 1. The mistake is that if your
> Page instance 2 handles saving procedure, it will save the target data
> {2} which does not receive the form submit.
> 
> This might work differently with detached models. I do not bother with
> detached models on lightweight models.
> 
> **
> Martin
> 
>>
>> MartinM wrote:
>>>
>>> Hi!
>>>
>>> I am having trouble with listView.setReuseitems(true).
>>>
>>> My problem is that
>>> 1. on first request the listview creates form components.
>>> 2. on second (or third ...) request the listView reuses the form
>>> components.
>>> 3. however, the propertymodels attached to the formcomponents at 1 are
>>> no longer viable, because their target objects are only the orignal
>>> serialization copies. In state 2 or 3 the form components now update
>>> totally obsolete instances of the target objects .
>>>
>>> A better strategy would probably be to just copy the rawInput states
>>> of the formComponents instead of really reusing the components.
>>>
>>> Comments, anybody? Did I misunderstand something? I have been
>>> debugging this for 6 hours now, maybe my brain melted down already. ..
>>>
>>> **
>>> Martin
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/reuseitems-problems-tp24702133p24704253.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

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


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

Re: Twenty Six Wicket Tricks

[Vladimir K]

Jeremy,

from my perspective ModalWindow is a mix of javascript widget that works in
non-wicket mode and an wicket wrapper that bridges js widget with wicket. It
is always created at the body level. That's why I said it's a cheat. Thus
are problems with form submitting when nested forms are used. Community
introduced a solution (a wrapping form that is threated as the root) to work
around the mismatch of ModalWindow structure. There is an issue registered
about that. But Matej keeps stating that we should put MW into a form. What
says that he is not aware what the problem is. And there are more problems
caused by the fact that the  element is created by javascript.

>From the other hand I believe it is possible to write pure Wicket component
that would be as trice as simpler and won't suffer with problems with
request lifecycle. Probably I'm wrong and it is not worth turning the old
ModalWindow into pure Wicket component due to expensiveness of the effort
that would be spent to remain it compatible.

The same about tree components. The API is very difficult to comprehend.
Component does not work as I expect in dynamic context. But thankfully Sven
implemented different implementation that does what is expect and usable as
well as DataTable component. I believe forking and fixing the original
component would be much more expensive. After that so many people should
start complaining about that to convince core team that there is not just
one person who is experiencing problems. It is always difficult to
accomplish.


jthomerson wrote:
> 
> Why create your own?  Submit a patch to fix what you see is wrong with
> the current one.  Everyone wins.
> 
> --
> Jeremy Thomerson
> http://www.wickettraining.com
> 
> 
> 
> 
> On Tue, Jul 28, 2009 at 12:20 PM, Vladimir K wrote:
>>
>> ModalWindow (being a wicket cheat :) ) deserves a sole book of tricks.
>> I'll
>> definitely author my own modal window unless someone fixes the original
>> one.
>> -1 on including ModalWindow to the book.
>>
>>
>> egolan74 wrote:
>>>
>>> I can't wait for yet another great Wicket book.
>>> I will surly buy it.
>>>
>>> regarding tricks,
>>> using Modal window can be nice.
>>> Integrating Wicket with JS libs (If it's not a topic for a small book by
>>> itself).
>>> Cool stuff with Ajax.
>>>
>>>
>>> Eyal Golan
>>> egola...@gmail.com
>>>
>>> Visit: http://jvdrums.sourceforge.net/
>>> LinkedIn: http://www.linkedin.com/in/egolan74
>>>
>>> P  Save a tree. Please don't print this e-mail unless it's really
>>> necessary
>>>
>>>
>>> On Tue, Dec 30, 2008 at 10:32 AM, Jonathan Locke
>>> wrote:
>>>
>>>>
>>>> Well, over the break here I've started something I swore I would never
>>>> do
>>>> again (well, two things, if you include the JavaOne talk I'm working
>>>> on).
>>>> I'm writing a (hopefully relatively short) book. It's called
>>>> "Twenty-Six
>>>> Wicket Tricks". Each trick in the book (lettered from A-Z) demonstrates
>>>> something that people typically want to do and in the process builds a
>>>> reusable and educational component. I've got 13 tricks coded up now and
>>>> ideas for a handful more, but if there are any requests out there,
>>>> please
>>>> let me know. I'd also be interested in getting some idea how many
>>>> people
>>>> would be interested in this book (would provide some fuel for me to get
>>>> it
>>>> done). It does not cover any of the same ground as Wicket in Action
>>>> (which
>>>> you should buy if you have not already!), BTW. It's more of a companion
>>>> to
>>>> that book.
>>>>
>>>> Happy Holidays!
>>>>
>>>> Best,
>>>>
>>>>       Jonathan
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Twenty-Six-Wicket-Tricks-tp21214357p21214357.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>> -
>>> Eyal Golan
>>> egola...@gmail.com

Re: reuseitems problems

[Vladimir K]

Martin,

please describe the context. I don't see how the process of serialization
makes the instance of the object obsolete.

In my practice I use a detachable model when rendering View page and I use a
static model when rendering an Edit page. In onSubmit method I save the
model object and forward the user to the View page.


MartinM wrote:
> 
> Hi!
> 
> I am having trouble with listView.setReuseitems(true).
> 
> My problem is that
> 1. on first request the listview creates form components.
> 2. on second (or third ...) request the listView reuses the form
> components.
> 3. however, the propertymodels attached to the formcomponents at 1 are
> no longer viable, because their target objects are only the orignal
> serialization copies. In state 2 or 3 the form components now update
> totally obsolete instances of the target objects .
> 
> A better strategy would probably be to just copy the rawInput states
> of the formComponents instead of really reusing the components.
> 
> Comments, anybody? Did I misunderstand something? I have been
> debugging this for 6 hours now, maybe my brain melted down already. ..
> 
> **
> Martin
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

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


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

Re: Twenty Six Wicket Tricks

[Vladimir K]

ModalWindow (being a wicket cheat :) ) deserves a sole book of tricks. I'll
definitely author my own modal window unless someone fixes the original one.
-1 on including ModalWindow to the book.


egolan74 wrote:
> 
> I can't wait for yet another great Wicket book.
> I will surly buy it.
> 
> regarding tricks,
> using Modal window can be nice.
> Integrating Wicket with JS libs (If it's not a topic for a small book by
> itself).
> Cool stuff with Ajax.
> 
> 
> Eyal Golan
> egola...@gmail.com
> 
> Visit: http://jvdrums.sourceforge.net/
> LinkedIn: http://www.linkedin.com/in/egolan74
> 
> P  Save a tree. Please don't print this e-mail unless it's really
> necessary
> 
> 
> On Tue, Dec 30, 2008 at 10:32 AM, Jonathan Locke
> wrote:
> 
>>
>> Well, over the break here I've started something I swore I would never do
>> again (well, two things, if you include the JavaOne talk I'm working on).
>> I'm writing a (hopefully relatively short) book. It's called "Twenty-Six
>> Wicket Tricks". Each trick in the book (lettered from A-Z) demonstrates
>> something that people typically want to do and in the process builds a
>> reusable and educational component. I've got 13 tricks coded up now and
>> ideas for a handful more, but if there are any requests out there, please
>> let me know. I'd also be interested in getting some idea how many people
>> would be interested in this book (would provide some fuel for me to get
>> it
>> done). It does not cover any of the same ground as Wicket in Action
>> (which
>> you should buy if you have not already!), BTW. It's more of a companion
>> to
>> that book.
>>
>> Happy Holidays!
>>
>> Best,
>>
>>   Jonathan
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Twenty-Six-Wicket-Tricks-tp21214357p21214357.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> 
> -
> Eyal Golan
> egola...@gmail.com
> 
> Visit: JVDrums 
> LinkedIn: LinkedIn 
> 

-- 
View this message in context: 
http://www.nabble.com/Twenty-Six-Wicket-Tricks-tp21214357p24704037.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Twenty Six Wicket Tricks

[Vladimir K]

+1
I will buy such trick


Erik van Oosten wrote:
> 
> Jonathan Locke wrote:
>>  I've got 13 tricks coded up now and
>> ideas for a handful more, but if there are any requests out there, please
>> let me know
>>   
> Perhaps something about handling URLs. Like writing your own url coding 
> strategy and how to mount pages with URL that have some variable before 
> the fixed parts (like /{language}/products/{productid}).
> 
> Regards,
> Erik.
> 
> 
> -- 
> Erik van Oosten
> http://www.day-to-day-stuff.blogspot.com/
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Twenty-Six-Wicket-Tricks-tp21214357p24703581.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: How to determine which behavior corresponds to the currently handled request target

[Vladimir K]

I'm trying to add AjaxFormComponentUpdating behavior to FormComponentPanel.
The latter is inherintly  not suited for Ajax requests. So I have to use
some workarounds to update model of FormComponentPanel by ajax update on
"onblur" js event on inner input, see code posted here. It works for now but
I'm afraid I should bypass updating of model when whole form is submitted
via ajax. So I'm trying to figure out what particular behavior is in
progress.

>From the other hand you probably know different way how to add
AjaxFormComponentUpdatingBehaviour to DateField component. Any thoughts are
welcome.


igor.vaynberg wrote:
> 
> you can use AjaxRequestTarget.get() to see if an ajax request is being
> processed.
> 
> -igor
> 
> On Mon, Jul 27, 2009 at 5:41 AM, Vladimir K wrote:
>>
>> Could anyone shed light on that?
>> --
>> View this message in context:
>> http://www.nabble.com/How-to-determine-which-behavior-corresponds-to-the-currently-handled--request-target-tp24635282p24680015.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/How-to-determine-which-behavior-corresponds-to-the-currently-handled--request-target-tp24635282p24686879.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: How to determine which behavior corresponds to the currently handled request target

[Vladimir K]

Could anyone shed light on that?
-- 
View this message in context: 
http://www.nabble.com/How-to-determine-which-behavior-corresponds-to-the-currently-handled--request-target-tp24635282p24680015.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: [ANN] wicket-tree project

[Vladimir K]

Since you update AbstractTree in ajax request I can't omit etra 'div' tag
that encloses  tag neither by using  nor by calling
setRenderBodyOnly(true).


Vladimir K wrote:
> 
> Sven,
> 
> i added TableTree (why not TreeTable?) to my panel and added a button to
> switch between tree and table representation.
> 
> The problem is that DataTable relies on the user that binds it to the
>  tag at the time when your TableTree contains  within.
> 
> It is not a big deal just an unconvinience. I have 12 lines of code and 5
> lines of markup instead of single addOrReplace call.
> 
> Hmm ... from the other hand I see a showstopper - I can't add my
> attributes and styles to TableTree because it is hidden inside. That's a
> big problem.
> 
> Please consider removing  tags from TableTree markup. You can make
> sure that the user provided correct tag in onComponentTag method.
> 

-- 
View this message in context: 
http://www.nabble.com/-ANN--wicket-tree-project-tp24660403p24672778.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: [ANN] wicket-tree project

[Vladimir K]

Sven,

i added TableTree (why not TreeTable?) to my panel and added a button to
switch between tree and table representation.

The problem is that DataTable relies on the user that binds it to the
 tag at the time when your TableTree contains  within.

It is not a big deal just an unconvinience. I have 12 lines of code and 5
lines of markup instead of single addOrReplace call.

Hmm ... from the other hand I see a showstopper - I can't add my attributes
and styles to TableTree because it is hidden inside. That's a big problem.

Please consider removing  tags from TableTree markup. You can make
sure that the user provided correct tag in onComponentTag method.
-- 
View this message in context: 
http://www.nabble.com/-ANN--wicket-tree-project-tp24660403p24671586.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: advice about ImageSubmitButton and AjaxImageSubmitButton

[Vladimir K]

In addition I need something like AjaxFallbackImageSubmitButton. Just to let
you know that he is not alone :)

>From my perspective Wicket should provide basic Button and mixins (mostly
behaviours) to add Ajax, AjaxFallback, Image, Submit etc. So users could
just get the button they need by adding mixins like bricks to the wall.


Martijn Dashorst wrote:
> 
> You are the first one to miss them, so they are not used very often :).
> They are easy enough to create yourself, -1 on adding more bloated buttons
> to the core.
> 
> Martijn
> 
> On Nov 29, 2007 10:17 AM, xiefei  wrote:
> 
>> In the "Button" type hierachy, there are ImageButton and
>> AjaxSubmitButton,
>> but no ImageSubmitButton or AjaxImageSubmitButton found.
>>
>> These two are also very often used in practice, worth being provided as
>> standard component.
>> _
>> Windows Live Photo gallery 数码相机的超级伴侣，轻松管理和编辑照片，还能制作全景美图！
>> http://get.live.cn/product/photo.html
> 
> 
> 
> 
> -- 
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0-rc1 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
> 
> 

-- 
View this message in context: 
http://www.nabble.com/advice-about-ImageSubmitButton-and-AjaxImageSubmitButton-tp14022088p24671164.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: [ANN] wicket-tree project

[Vladimir K]

It does not. It is stated at the bottom of the home page
http://code.google.com/p/wicket-tree/
For ajax updates it should behave not worse than DataTable component.

Matej, I find the idea of re-using data provider, columns and cells
developed for DataTable very important.


Matej Knopp-2 wrote:
> 
> Does TableTree support partial (ajax) updates?
> 
> -Matej
> 
> On Sun, Jul 26, 2009 at 3:00 PM, Vladimir K wrote:
>>
>>
>> svenmeier wrote:
>>>
>>> ITreeProvider and IDataProvider are not exactly compatible, I don't
>>> think we gain anything by extending the former from the latter.
>>>
>>
>> I don't insist. But you do have IDataProvider wrapper over ITreeProvider
>> in
>> TableTree.java :)
>>
>>
>>
>>> Selection is not part of the tree components. There are just to many
>>> different notions of selection:
>>> - single/multiple selection
>>> - subtree selection
>>> - continuous/discontinuous selection
>>> - several selections on a single tree (see example with checkable *and*
>>> selectable content)
>>> - no selection at all
>>> - ...
>>>
>>> IMHO it's better to leave these requirements out of a tree
>>> implementation.
>>> If you need a "selected" class attribute on a TableTree, override
>>> #newRowItem() and do it yourself. Ever noticed that DataTable has no
>>> notion of selection too?
>>>  tag. Whatever.
>>
>> I din't find API to control expanded state of node. Say I would like to
>> add
>> a button to collapse all nodes, or I would like to save expanded state
>> and
>> restore when the user returns back to this page again.
>>
>> Please explain how I should operate with the state of tree (what nodes
>> are
>> expanded and what nodes are selected). Once I realize I will be able to
>> override newRowItem properly.
>>
>> Also you have 2 Branch classes. I find it confusing a bit.
>>
>> I'm going to play with TreeTable tomorrow.
>>
>> --
>> View this message in context:
>> http://www.nabble.com/-ANN--wicket-tree-project-tp24660403p24666766.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-ANN--wicket-tree-project-tp24660403p24666861.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: [ANN] wicket-tree project

[Vladimir K]

svenmeier wrote:
> 
> ITreeProvider and IDataProvider are not exactly compatible, I don't
> think we gain anything by extending the former from the latter.
> 

I don't insist. But you do have IDataProvider wrapper over ITreeProvider in
TableTree.java :)



> Selection is not part of the tree components. There are just to many
> different notions of selection:
> - single/multiple selection
> - subtree selection
> - continuous/discontinuous selection
> - several selections on a single tree (see example with checkable *and*
> selectable content)
> - no selection at all
> - ...
> 
> IMHO it's better to leave these requirements out of a tree
> implementation.
> If you need a "selected" class attribute on a TableTree, override
> #newRowItem() and do it yourself. Ever noticed that DataTable has no
> notion of selection too?
>  tag. Whatever.

I din't find API to control expanded state of node. Say I would like to add
a button to collapse all nodes, or I would like to save expanded state and
restore when the user returns back to this page again.

Please explain how I should operate with the state of tree (what nodes are
expanded and what nodes are selected). Once I realize I will be able to
override newRowItem properly.

Also you have 2 Branch classes. I find it confusing a bit.

I'm going to play with TreeTable tomorrow.

-- 
View this message in context: 
http://www.nabble.com/-ANN--wicket-tree-project-tp24660403p24666766.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: [ANN] wicket-tree project

[Vladimir K]

Just make IDataProvider in charge for sorting and filtering like DataTable
does.

Filtering in tree could be seen in Eclipse preferences for instance.


svenmeier wrote:
> 
> Hi,
> 
> I've added single selection to the example. I'm not sure how sorting and
> filtering applies to hierarchical data though.
> 
> API will be finalized after sufficient feedback from the Wicket
> community - so keep on firing questions ;).
> 
> Sven
> 
> On So, 2009-07-26 at 01:51 -0700, Vladimir K wrote:
>> Nested tree and tree table seems promicing.
>> 
>> What I missed in your example is single-selection mode, and sortable
>> headers
>> with filters.
>> 
>> One of my the upcoming tasks is to build a selector component that knows
>> whether the object is hierarchical and puts inside a datatable with
>> navigator or treetable. Since wicket-extentions project has completely
>> incompatible components in this regard my component that unifies both
>> looks
>> pretty complex to do. Your treetable components seems to be more close to
>> datable so it definitely might come in handy.
>> 
>> When are you going to finalize the component contract (api)?
>> 
>> 
>> svenmeier wrote:
>> > 
>> > Sure, wicket-tree is still in its conception phase.
>> > 
>> > I'll tidy up the project structure soon.
>> > 
>> > Sven
>> > 
>> > On Sa, 2009-07-25 at 18:57 -0400, James Carman wrote:
>> >> So is the project a war (since it runs with jetty:run)?  Wouldn't that
>> >> make
>> >> it hard to use in other projects?
>> >> 
>> >> On Jul 25, 2009 6:18 PM, "Major Péter"  wrote:
>> >> 
>> >> Cool, that was exactly, what I was looking for.
>> >> Thanks.
>> >> 
>> >> Peter
>> >> 
>> >> 2009-07-26 00:06 keltezéssel, Sven Meier írta:
>> >> 
>> >> > > Hi Peter, > >> // at the chekcedfoldercontent (nested tree)
>> example
>> >> if I
>> >> check the >> parent, t...
>> > 
>> > 
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> > 
>> > 
>> > 
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-ANN--wicket-tree-project-tp24660403p24665608.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Reading Wicket source code

[Vladimir K]

For me the magic is how wicket is managing pages and their versions. For
instance I realized that it increments version when preparing the page for
render. But when I was debugging the code related to version manager I felt
lost :)
All the other stuff is pretty complex but not difficult to understand.


MartinM wrote:
> 
> Also one very benefiial point of view is just to code something and
> when you find a bug (either in your own code or Wicket), debug through
> wicket source and find the cause. If it's a wicket bug -> contribute
> quickstart to jira that repeats the bug. I have learned myself quite a
> bit by doing this. However, I am still a bit puzzled with wicket's
> request cycle, there seems to still to be some magic going on ... ;)
> 
> **
> Martin
> 
> 2009/7/24 Pierre Goupil :
>> Good evening,
>>
>> In order to learn Wicket as well as good Java coding ^ ^, I'd like to
>> read
>> Wicket source code. It's been a couple of months since I use it, so I
>> have a
>> general user-view on it.
>>
>> Do you have advice ? Where should I start it all ? Is there any typical
>> workflow through the code-base for such a matter ?
>>
>> Hope to hear from you soon, guys !
>>
>> Regards,
>>
>> Pierre
>>
>>
>>
>> --
>> Sans amis était le grand maître des mondes,
>> Eprouvait manque, ce pour quoi il créa les esprits,
>> Miroirs bienveillants de sa béatitude.
>> Mais au vrai, il ne trouva aucun égal,
>> Du calice du royaume total des âmes
>> Ecume jusqu'à lui l'infinité.
>>
>> (Schiller, "l'amitié")
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Reading-Wicket-source-code-tp24651141p24665454.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: [ANN] wicket-tree project

[Vladimir K]

I find the source code pretty clean and easy to understand. Especially if you
are familiar with DataTable component. For instance I see that it is easy to
use Ajax versions of Toolbars instead of static (however
DefaultAjaxFallbackTreeTable would be usefull)

Looking forward for the post-conception version :)

I would suggest adding it to the Wicket right next to DataTable.

-- 
View this message in context: 
http://www.nabble.com/-ANN--wicket-tree-project-tp24660403p24665301.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: [ANN] wicket-tree project

[Vladimir K]

Why you don't extend ITreeProvider from IDataProvider? They looks compatible
for now. I can add IDataProvider to my implementation class and delegate
roots() to iterator(). From the other hand it is just extra method.

One thing to mention. There should be "full row select" option. You just
need to add a "selected" class attribute for selected s.


Vladimir K wrote:
> 
> Nested tree and tree table seems promicing.
> 
> What I missed in your example is single-selection mode, and sortable
> headers with filters.
> 
> One of my the upcoming tasks is to build a selector component that knows
> whether the object is hierarchical and puts inside a datatable with
> navigator or treetable. Since wicket-extentions project has completely
> incompatible components in this regard my component that unifies both
> looks pretty complex to do. Your treetable components seems to be more
> close to datable so it definitely might come in handy.
> 
> When are you going to finalize the component contract (api)?
> 
> 
> svenmeier wrote:
>> 
>> Sure, wicket-tree is still in its conception phase.
>> 
>> I'll tidy up the project structure soon.
>> 
>> Sven
>> 
>> On Sa, 2009-07-25 at 18:57 -0400, James Carman wrote:
>>> So is the project a war (since it runs with jetty:run)?  Wouldn't that
>>> make
>>> it hard to use in other projects?
>>> 
>>> On Jul 25, 2009 6:18 PM, "Major Péter"  wrote:
>>> 
>>> Cool, that was exactly, what I was looking for.
>>> Thanks.
>>> 
>>> Peter
>>> 
>>> 2009-07-26 00:06 keltezéssel, Sven Meier írta:
>>> 
>>> > > Hi Peter, > >> // at the chekcedfoldercontent (nested tree) example
>>> if I
>>> check the >> parent, t...
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-ANN--wicket-tree-project-tp24660403p24665206.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: [ANN] wicket-tree project

[Vladimir K]

Nested tree and tree table seems promicing.

What I missed in your example is single-selection mode, and sortable headers
with filters.

One of my the upcoming tasks is to build a selector component that knows
whether the object is hierarchical and puts inside a datatable with
navigator or treetable. Since wicket-extentions project has completely
incompatible components in this regard my component that unifies both looks
pretty complex to do. Your treetable components seems to be more close to
datable so it definitely might come in handy.

When are you going to finalize the component contract (api)?


svenmeier wrote:
> 
> Sure, wicket-tree is still in its conception phase.
> 
> I'll tidy up the project structure soon.
> 
> Sven
> 
> On Sa, 2009-07-25 at 18:57 -0400, James Carman wrote:
>> So is the project a war (since it runs with jetty:run)?  Wouldn't that
>> make
>> it hard to use in other projects?
>> 
>> On Jul 25, 2009 6:18 PM, "Major Péter"  wrote:
>> 
>> Cool, that was exactly, what I was looking for.
>> Thanks.
>> 
>> Peter
>> 
>> 2009-07-26 00:06 keltezéssel, Sven Meier írta:
>> 
>> > > Hi Peter, > >> // at the chekcedfoldercontent (nested tree) example
>> if I
>> check the >> parent, t...
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-ANN--wicket-tree-project-tp24660403p24665096.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Serialization of a page with a long and dynamic list of records

[Vladimir K]

I realized that it is not possible to support bookmarkable page links in
breadcrumbs panel for already instantiated pages because it won't work with
multiple browser windows and tabls.

Therefore I can use bookmarkable links for non-instantiated pages only. It
can be easily accomplished with existing components. Hmm ... wrong word. ...
EASIER than overriding page factory.
-- 
View this message in context: 
http://www.nabble.com/how-to-create-a-BookmarkablePageLink-for-the-particular-page-instance-tp24659102p24662729.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: how to create a BookmarkablePageLink for the particular page instance

[Vladimir K]

Certainly, parameters are just name of object class and object code/id.
But actually I'm saying that I can create store PageReference with its
related PageParametes in session and using PageParameters from the request
to obtain a Page instance from page store.
The only thing I'm not sure is the lifecycle of values in such a cache.

AFAK overriding page factory is the only way how to make a page singleton in
the session. There are plenty of pages that should behave as singleton.
There would be the other way if it was easy to split Tree and its DYNAMIC
state. Unfortunately tree is very difficult in restoring its state.

The user don't want to expand tree items every time she has to return back
to the page.


Alexandru Objelean wrote:
> 
> If you can restore the page state from passed PageParameters, then it is
> doable...
> 
> Alex Objelean
> 
> 

-- 
View this message in context: 
http://www.nabble.com/how-to-create-a-BookmarkablePageLink-for-the-particular-page-instance-tp24659102p24659535.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: how to create a BookmarkablePageLink for the particular page instance

[Vladimir K]

It seems that I can override page factory in session and re-use existing page
basing on the parameters values.


Alexandru Objelean wrote:
> 
> Bookmarkable page doesn't have state and can be created using
> PageParameters. Each request for a bookmarkable page will cause a creation
> of new instance of that page. In your case, if the page instance have some
> state (is session relative), then there is no way to create a bookmarkable
> link for it.
> 
> Alex Objelean 
> 
> 
> Vladimir K wrote:
>> 
>> I created a breadcrumbs panel that automatically creates a series of
>> bookmarkable links from the home page to the page that displays a details
>> of
>> currently viewing entity instance.
>> Usually it looks like for instance
>> home|folders|folder1|folder1.1|document
>> 
>> From the other hand when the user comes to this particular document by
>> opening folders and then the document itself she produces a page versions
>> that makes page history. There is an button "back" or "close" on the page
>> that returns the user to the previous page in the history.
>> 
>> As the result breadcrumbs and history forms two different ways of
>> navigation
>> but they both are natural and required.
>> 
>> The problem is that clicking on the particular link in breadcrumb panel
>> leads to creating a new version of page. I use HybridUrlCodingStrategy
>> and
>> it seems pretty possible to add version attributes to the url. But I
>> don't
>> know how to do it in compatible manner. It seems that the only link that
>> forms the bookmarkable URL using hybrid strategy is the
>> BookmarkablePageLink. But it does not accept anything from the particular
>> page version.
>> 
>> Please help
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/how-to-create-a-BookmarkablePageLink-for-the-particular-page-instance-tp24659102p24659419.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: how to strip wicket tags for particular component

[Vladimir K]

It is possible to override onRender method. It turned out that it is not
final.

@Override
protected void onRender(MarkupStream markupStream) {
Application.get().getMarkupSettings().setStripWicketTags(true);
try {
super.onRender(markupStream);
} finally {

Application.get().getMarkupSettings().setStripWicketTags(

MyApplication.STRIP_WICKET_TAGS_IN_DEVELOPMENT_MODE);
}
}

But I don't find appropriate method to override to let children render
wicket tags.

-- 
View this message in context: 
http://www.nabble.com/how-to-strip-wicket-tags-for-particular-component-tp24568122p24569807.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: how to strip wicket tags for particular component

[Vladimir K]

it seems that onAfterRender is not the appropriate place to restore settings
... :(


Vladimir K wrote:
> 
> Mathias,
> 
> I just posted right after your post :) Anyway thanks.
> 
> The problem is that you can not restore origianal settings when the body
> of the border is being rendered. At lease it is difficult to figure out
> what workaround I could employ.
> 
> Thankfully I don't have to care about that in my case so I use it.
> 
> 
> Mathias Nilsson wrote:
>> 
>> This may not be the best solution but it should work
>> 
>> DateTextField  dateField = new DateTextField("date", new Model(new
>> Date())){
>>  @Override
>>  protected void onBeforeRender() {
>>  
>>  
>> Application.get().getMarkupSettings().setStripWicketTags(true);
>>  super.onBeforeRender();
>>  }
>>  @Override
>>  protected void onAfterRender() {
>>  
>> Application.get().getMarkupSettings().setStripWicketTags(false);
>>  super.onAfterRender();
>>  }
>> 
>>  }; 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/how-to-strip-wicket-tags-for-particular-component-tp24568122p24569561.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: how to strip wicket tags for particular component

[Vladimir K]

Mathias,

I just posted right after your post :) Anyway thanks.

The problem is that you can not restore origianal settings when the body of
the border is being rendered. At lease it is difficult to figure out what
workaround I could employ.

Thankfully I haven't to care about that in my case so I use it.


Mathias Nilsson wrote:
> 
> This may not be the best solution but it should work
> 
> DateTextField  dateField = new DateTextField("date", new Model(new
> Date())){
>   @Override
>   protected void onBeforeRender() {
>   
>   
> Application.get().getMarkupSettings().setStripWicketTags(true);
>   super.onBeforeRender();
>   }
>   @Override
>   protected void onAfterRender() {
>   
> Application.get().getMarkupSettings().setStripWicketTags(false);
>   super.onAfterRender();
>   }
> 
>   }; 
> 

-- 
View this message in context: 
http://www.nabble.com/how-to-strip-wicket-tags-for-particular-component-tp24568122p24568972.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: how to strip wicket tags for particular component

[Vladimir K]

For now I use the following workaround

public class CleanBorder extends Border {
private boolean savedStripWicketTags; 

public CleanBorder(String id) {
super(id);
setRenderBodyOnly(true);
getBodyContainer().setRenderBodyOnly(true);
}

public CleanBorder(String id, IModel model) {
super(id, model);
setRenderBodyOnly(true);
getBodyContainer().setRenderBodyOnly(true);
}

@Override
protected void onAfterRender() {
super.onAfterRender();

Application.get().getMarkupSettings().setStripWicketTags(savedStripWicketTags);
}

@Override
protected void onBeforeRender() {
savedStripWicketTags =
Application.get().getMarkupSettings().getStripWicketTags();
Application.get().getMarkupSettings().setStripWicketTags(true);
super.onBeforeRender();
}


that looks like a hack. I would prefer a settings on the MarkupContainer
that by default uses the application settings but in case of border can be
overridden.


Vladimir K wrote:
> 
> I'm trying to convert main menu into components to control visibility of
> items depending on the user logged in and the context.
> I use borders to wrap menu item into  tags.
> 
> The problem is that the rendered markup contains additional
> 
> and  tags. They breaks the menu and it is eventually
> displayed
> as the simple list.
> 
> Stripping wicket tags at the application level would obviously solve the
> problem. But I'd like to keep wicket tags for most markup and strip only
> for
> menu.
> 
> Can I override Border class somehow and strip wicket tags manually?
> 
> 

-- 
View this message in context: 
http://www.nabble.com/how-to-strip-wicket-tags-for-particular-component-tp24568122p24568909.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: model detached many times

[Vladimir K]

Martijn,

you probably mean how chained models would be detached. So instead of
propagating detach in IChainedModel they would be detached automatically?

Is there a vision how it would be accomplished?


Martijn Dashorst wrote:
> 
> Automatic detachment is one of the things we're looking into for 1.5 or
> 1.6
> 
> Martijn
> 
> On Fri, Jul 10, 2009 at 12:47 PM, James
> Carman wrote:
>> Perhaps there could be some sort of registry for models that need to
>> be detached.  Then, after rendering, they're all detached as part of
>> the request cycle?
>>
>> On Fri, Jul 10, 2009 at 4:00 AM, Martijn
>> Dashorst wrote:
>>> If you share a model between components, then yes–each component will
>>> call detach on the model. That's encapsulation for you: one component
>>> doesn't know about another component, so it can't know that its model
>>> was detached.
>>>
>>> Martijn
>>>
>>> On Fri, Jul 10, 2009 at 9:41 AM, Ian MacLarty
>>> wrote:
 I put a breakpoint on the detach method of my model and had a look at
 the Components whose detach methods were called higher up in the stack
 trace.  It looks like the detach method on the model is being called
 for every component on the page.  All the components link to the same
 underlying model via a CompoundPropertyModel, so I guess lots of calls
 to the detach method of the model should be expected?

 Ian.

 On Fri, Jul 10, 2009 at 5:17 PM, Eelco
 Hillenius wrote:
> It's fine if a model if detached multiple times in a request, but
> hundreds for a single model sounds suspicious. Try to trace what
> components fire the detach method and see if there's anything weird
> with that.
>
> Eelco
>
> On Thu, Jul 9, 2009 at 11:21 PM, Ian MacLarty
> wrote:
>> Hi,
>>
>> I noticed that my IDetachable model is being detached many times
>> (hundreds) for each request.  Is that something to worry about, or is
>> it just because the detach method is called for each component that
>> points to this model?
>>
>> Ian.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

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


>>>
>>>
>>>
>>> --
>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>> Apache Wicket 1.3.5 is released
>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> 
> 
> -- 
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.5 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/model-detached-many-times-tp24422368p24457432.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: MixedHybridUrlCodingStrategy wanted

[Vladimir K]

Thanks very much!

Why not suggest it as a patch to wicket core?


Erik van Oosten wrote:
> 
> Hi Vladimir,
> 
> You are right. Now I look at it, it is clearly more complex then I 
> remembered.
> 
> You can get my version here: http://pastie.org/543892
> 
> Regards,
> Erik.
> 
> 
> Vladimir K wrote:
>> I didn't find it easy to do it myself. By easy I mean what I can
>> accomplish
>> within 15 mins.
>>
>> From the first glance it looks just like a mix of two strategies but it
>> actually does not. MixedHybridUrlCodingStrategy should handle all the
>> parameters delimited by slashes and some of them have names omitted.
>> Original Mixed strategy operates with regular parameters syntax. I
>> believe
>> it would take some hours to study what strategies do internally and
>> implement and test mixed solution. I hoped someone have already tried
>> that.
>>
>> Unfortunately I didn't find anything by google and nabble so I posted the
>> question here. If you could point me some old discussion I'd appreciate.
>>
>>
>> Erik van Oosten wrote:
>>   
>>> It is fairly easy to construct it yourself. Just look at the code of 
>>> MixedParamUrlCodingStrategy, copy it and replace the class you're 
>>> extending to the corresponding HybridUrlCodingStrategy.
>>>
>>> Its also on the mailing list, search the archives. Lastly, the 
>>> annotation based mounting project (forgot the name) contains it.
>>>
>>> Regards,
>>>  Erik.
>>>
>>>
>>>
>>> Vladimir Kovalyuk wrote:
>>> 
>>>> Is there a worked combination of HybridUrlCodingStrategy and
>>>> MixedParamUrlCodingStrategy? What is missed in the latter is ability to
>>>> stay
>>>> bookmarkable after reaction on actions.
>>>>
>>>>   
>>>>   
>>> -- 
>>> Erik van Oosten
>>> http://www.day-to-day-stuff.blogspot.com/
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>>
>>> 
>>
>>   
> 
> -- 
> 
> Erik van Oosten
> http://day-to-day-stuff.blogspot.com/
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

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


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

Re: MixedHybridUrlCodingStrategy wanted

[Vladimir K]

I didn't find it easy to do it myself. By easy I mean what I can accomplish
within 15 mins.

>From the first glance it looks just like a mix of two strategies but it
actually does not. MixedHybridUrlCodingStrategy should handle all the
parameters delimited by slashes and some of them have names omitted.
Original Mixed strategy operates with regular parameters syntax. I believe
it would take some hours to study what strategies do internally and
implement and test mixed solution. I hoped someone have already tried that.

Unfortunately I didn't find anything by google and nabble so I posted the
question here. If you could point me some old discussion I'd appreciate.


Erik van Oosten wrote:
> 
> It is fairly easy to construct it yourself. Just look at the code of 
> MixedParamUrlCodingStrategy, copy it and replace the class you're 
> extending to the corresponding HybridUrlCodingStrategy.
> 
> Its also on the mailing list, search the archives. Lastly, the 
> annotation based mounting project (forgot the name) contains it.
> 
> Regards,
>  Erik.
> 
> 
> 
> Vladimir Kovalyuk wrote:
>> Is there a worked combination of HybridUrlCodingStrategy and
>> MixedParamUrlCodingStrategy? What is missed in the latter is ability to
>> stay
>> bookmarkable after reaction on actions.
>>
>>   
> 
> 
> -- 
> Erik van Oosten
> http://www.day-to-day-stuff.blogspot.com/
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

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


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

Re: wicket vs vaadin clarifications

[Vladimir K]

Joonas Lehtinen wrote:
> 
> 
> I only included frameworks that I get the most questions about. We
> definitely should include ZK also, but validating some facts would need
> some quick research. If you are familiar with ZK, could you contribute ZK
> column to the comparison table?
> 

No, I'm not familiar with ZK enough to contribute a column. Amount of its
ads is quite impressive so I assume it has a certain piece of market pie.
However I refused ZK 'cause it looks not so attractive in technical
internals.


Joonas Lehtinen wrote:
> 
> 
> Vladimir K wrote:
>> 
>> I find Vaadin demos not very responsive. They react very very slowly. At
>> that internet responses are less than 100ms and response size mostly less
>> than 1K and there are only one-two roundtrips for each user action. The
>> same about every GWT application.
>> 
> 
> That is strange. Did you try the demos on http://demo.vaadin.com/ that is
> hosted in USA (Amazon EC2 EAST) or did you run the demos from local server
> (download vaadin package and run start.sh)?
> 

I run online demo. It just came to my mind that this sort of discussion
probably is offtopic.
-- 
View this message in context: 
http://www.nabble.com/wicket-vs-vaadin-clarifications-tp24353170p24413008.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: wicket vs vaadin clarifications

[Vladimir K]

Joonas,

I'm wondering why your comparison table does not contain ZK?

I find Vaadin demos not very responsive. They react very very slowly. At
that internet responses are less than 100ms and response size mostly less
than 1K and there are only one-two roundtrips for each user action. The same
about every GWT application.

Wicket ajax responses in our application sometimes exceeds 30k and I don't
notice any lags.


Joonas Lehtinen wrote:
> 
> Hi all, 
> 
> If there are any errors in our comparison table, please accept my
> apologies - 
> I wrote the original version of the table. I take care that any errors
> will be
> corrected as soon as possible. Just to clarify the situation - I think
> that 
> wicket is a nice framework and really want to give it a fair comparison. 
> In my opinion, Vaadin is better for some applications and Wicket for some.
> 
> 

-- 
View this message in context: 
http://www.nabble.com/wicket-vs-vaadin-clarifications-tp24353170p24409410.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Can I make AjaxFormSubmitBehavior submit raw form data but not validate it?

[Vladimir K]

Igor, for now I'm concerned about how can I make sure that my code that
mimics form submitting lifecycles and wicket code in coming version do the
same things?

For instance the AjaxFormComponentUpdatingBehavior:

@Override
protected final void onEvent(final AjaxRequestTarget target)
{
final FormComponent formComponent = getFormComponent();

if (getEvent().toLowerCase().equals("onblur") && 
disableFocusOnBlur())
{
target.focusComponent(null);
}

try
{
formComponent.inputChanged();
formComponent.validate();
if (formComponent.hasErrorMessage())
{
formComponent.invalid();

onError(target, null);
}
else
{
formComponent.valid();
if (getUpdateModel())
{
formComponent.updateModel();
}

onUpdate(target);
}
}
catch (RuntimeException e)
{
onError(target, e);

}
}

I should do something similar but for the list of components the behavior
takes.
If the coming version of Wicket does it a bit different I would have to
insert a fork in my code that does version check:

switch(wicketVersion) {
case ...:
case ...:
}

If wicket sources had the form processing code extracted into utility class
I would employ it and be sure it should work in the new wicket version.


igor.vaynberg wrote:
> 
> you can see how the submit behavior does it and replicate the parts
> you need. all these things are not using some magical internal apis.
> you are meant to build your own things when the default
> implementations do not do what you want.
> 
> -igor
> 
> On Tue, Jul 7, 2009 at 6:35 AM, Thierry Leveque wrote:
>> Thanks, but I was not talking about using the submit behavior.
>>
>> I was talking about the way to create my own ajax behavior to send the
>> value
>> of multiple form fields.
>>
>> I think this should be part of Wicket. It is not the first time I
>> encounter
>> this problem. The first time, I found a workaround but this time I am
>> stuck.
>> There should be a simple way to create an ajax behavior that will send
>> the
>> values from the form components we want. Maybe with the option to
>> validate
>> them or not.
>> What do you think?
>>
>> Thierry
>>
>>
>> 2009/7/7 Stefan Malmesjö 
>>
>>> I just realized that maybe you need to extend your validators, too, at
>>> least if you want your modelobject to be updated. And how you do that on
>>> a
>>> textfield that is required, I don't really know.
>>>
>>> Maybe that path is too complicated.
>>>
>>> /Stefan
>>>
>>> On 2009-07-06 22:55, Stefan Malmesjö wrote:
>>>
 Could setting visibility for the FeedbackPanel to false until the form
 has
 been "properly" submitted with a press of a submit button work?

 /Stefan

 On Mon, Jul 6, 2009 at 8:42 PM, Thierry Leveque
 >>> tleve...@gmail.com>> wrote:

    Any following on that?

    Daniel, have you been able to solve your problem? Did you wrote
    your own
    behavior?

    I have the same requirement as you and I am trying to find a quick
    way to
    solve my problem.

    Can someone point me to some examples on how to write my own Ajax
    behavior?

    Thanks

    Thierry


    On Tue, Jun 2, 2009 at 12:21, Igor Vaynberg
    mailto:igor.vaynb...@gmail.com>> wrote:

    > well, if you do not want to *submit* the form then dont use
    > ajaxformSUBMITbehavior :)
    >
    > with little work you can roll your own behavior that does a simple
    > ajax get and appends whatever values you need from formcomponents
 to
    > the url. that way the form is not submitted and you have access
    to the
    > raw values.
    >
    > -igor
    >
    >
    >
    > On Tue, Jun 2, 2009 at 9:16 AM, dfernandez
    > >>>    > wrote:
    > >
    > >
    > > Yes, I know it is tricky, but the fact is I don't think I
    would really
    > need
    > > type conversion in this case.
    > >
    > > I will try to explain myself. I have the following UI:
    > >
    > >    |OPERATOR |V|
    > >
    > >    |INPUT1="aBc"        |     |INPUT2="DeF"          |
    > >
    > > ...being "OPERATOR" the DropDownChoice, and both INPUT1 and
    INPUT2 two
    > > TextFields (String TextFields, to

Re: Prefill form not model?

[Vladimir K]

Martin,

having read the thread I didn't get why you can not modify the object
itself. OSiV shouldn't be the reason because the object should be detached
when submitting the form and it should be merged into a brand new hibernate
session.

Actually I don't see the value of always keeping in mind that the raw input
and backed object should have different values until final form submit. If
your reusable components can submit form and aren't aware about that you
can't reuse them in that sort of form. From my perspective your hack does
not seem cleaner.

What i'm doing in order to set the default value (for instance today for
date picker) is subclassing form component and initialize its model object.
It looks shorter and cleaner.


MartinM wrote:
> 
>> Typically to prefill a form you have the backing model object have
>> sensible defaults.  i.e., a form that edits a person is given a
>> person, and the person object has it's gender set to "male" as a
>> default - that is reflected in your form when it is rendered.
> 
> The problem is that it is not a NEW object. It is an old object with
> "proposed new values" which the user must SUBMIT in order to be stored
> into the object etc.
> 
>> otherwise, you could call setModelObject or perhaps setValue?
> 
> Well.. that will destroy the object state, which is a different hassle.
> 
> **
> Martin
> 
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>>
>>
>> On Tue, Jul 7, 2009 at 8:57 AM, Martin
>> Makundi wrote:
>>> Hi!
>>>
>>> What is the proper way to prefill a wicket form (not poke the model
>>> before submit!!!)?
>>>
>>> I have used a hack:
>>>
>>>      Field rawInputField =
>>> FormComponent.class.getDeclaredField("rawInput");
>>>      rawInputField.setAccessible(true);
>>>      rawInputField.set(component, description);
>>>
>>> Is there a better way?
>>>
>>> **
>>> Martin
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Prefill-form-not-model--tp24373824p24386875.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Can I make AjaxFormSubmitBehavior submit raw form data but not validate it?

[Vladimir K]

Wicket has strong rules how to handle ajax form submit. Therefore partial
form submitting should be handled differently on the server side.
Anyway we could handle raw strings or invoke converter ourselves.


Vladimir K wrote:
> 
> From the ajax perspective it should be possible to submit any dom element
> with its descendants. I believe it is exactly what Wicket ajax submit is
> doing. IMO forms needed just for regular form submit.
> 
> We just need to change an implementation to accept a list of dom elements
> instead of just one.
> 
> I don't have an opinion about reasons to handle partial form submitting
> lifecycle on the server side.
> 
> 
> tleveque wrote:
>> 
>> Thanks, but I was not talking about using the submit behavior.
>> 
>> I was talking about the way to create my own ajax behavior to send the
>> value
>> of multiple form fields.
>> 
>> I think this should be part of Wicket. It is not the first time I
>> encounter
>> this problem. The first time, I found a workaround but this time I am
>> stuck.
>> There should be a simple way to create an ajax behavior that will send
>> the
>> values from the form components we want. Maybe with the option to
>> validate
>> them or not.
>> What do you think?
>> 
>> Thierry
>> 
>> 
>> 2009/7/7 Stefan Malmesjö 
>> 
>>> I just realized that maybe you need to extend your validators, too, at
>>> least if you want your modelobject to be updated. And how you do that on
>>> a
>>> textfield that is required, I don't really know.
>>>
>>> Maybe that path is too complicated.
>>>
>>> /Stefan
>>>
>>> On 2009-07-06 22:55, Stefan Malmesjö wrote:
>>>
>>>> Could setting visibility for the FeedbackPanel to false until the form
>>>> has
>>>> been "properly" submitted with a press of a submit button work?
>>>>
>>>> /Stefan
>>>>
>>>> On Mon, Jul 6, 2009 at 8:42 PM, Thierry Leveque
>>>> >>> tleve...@gmail.com>> wrote:
>>>>
>>>>Any following on that?
>>>>
>>>>Daniel, have you been able to solve your problem? Did you wrote
>>>>your own
>>>>behavior?
>>>>
>>>>I have the same requirement as you and I am trying to find a quick
>>>>way to
>>>>solve my problem.
>>>>
>>>>Can someone point me to some examples on how to write my own Ajax
>>>>behavior?
>>>>
>>>>Thanks
>>>>
>>>>Thierry
>>>>
>>>>
>>>>On Tue, Jun 2, 2009 at 12:21, Igor Vaynberg
>>>>mailto:igor.vaynb...@gmail.com>> wrote:
>>>>
>>>>> well, if you do not want to *submit* the form then dont use
>>>>> ajaxformSUBMITbehavior :)
>>>>>
>>>>> with little work you can roll your own behavior that does a simple
>>>>> ajax get and appends whatever values you need from formcomponents
>>>> to
>>>>> the url. that way the form is not submitted and you have access
>>>>to the
>>>>> raw values.
>>>>>
>>>>> -igor
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 2, 2009 at 9:16 AM, dfernandez
>>>>> >>><mailto:dfernan...@users.sourceforge.net>> wrote:
>>>>> >
>>>>> >
>>>>> > Yes, I know it is tricky, but the fact is I don't think I
>>>>would really
>>>>> need
>>>>> > type conversion in this case.
>>>>> >
>>>>> > I will try to explain myself. I have the following UI:
>>>>> >
>>>>> >|OPERATOR |V|
>>>>> >
>>>>> >|INPUT1="aBc"| |INPUT2="DeF"  |
>>>>> >
>>>>> > ...being "OPERATOR" the DropDownChoice, and both INPUT1 and
>>>>INPUT2 two
>>>>> > TextFields (String TextFields, to be precise). Both INPUT1 and
>>>>INPUT2 are
>>>>> > required (when they are visible, of course).
>>>>> >
>>>>> > When I change the value on "OPERATOR", the UI will change,
>

Re: Can I make AjaxFormSubmitBehavior submit raw form data but not validate it?

[Vladimir K]

>From the ajax perspective it should be possible to submit any dom element
with its descendants. I believe it is exactly what Wicket ajax submit is
doing. IMO forms needed just for regular form submit.

We just need to change an implementation to accept a list of dom elements
instead of just one.

I don't have an opinion about reasons to handle partial form submitting
lifecycle on the server side.


tleveque wrote:
> 
> Thanks, but I was not talking about using the submit behavior.
> 
> I was talking about the way to create my own ajax behavior to send the
> value
> of multiple form fields.
> 
> I think this should be part of Wicket. It is not the first time I
> encounter
> this problem. The first time, I found a workaround but this time I am
> stuck.
> There should be a simple way to create an ajax behavior that will send the
> values from the form components we want. Maybe with the option to validate
> them or not.
> What do you think?
> 
> Thierry
> 
> 
> 2009/7/7 Stefan Malmesjö 
> 
>> I just realized that maybe you need to extend your validators, too, at
>> least if you want your modelobject to be updated. And how you do that on
>> a
>> textfield that is required, I don't really know.
>>
>> Maybe that path is too complicated.
>>
>> /Stefan
>>
>> On 2009-07-06 22:55, Stefan Malmesjö wrote:
>>
>>> Could setting visibility for the FeedbackPanel to false until the form
>>> has
>>> been "properly" submitted with a press of a submit button work?
>>>
>>> /Stefan
>>>
>>> On Mon, Jul 6, 2009 at 8:42 PM, Thierry Leveque
>>> >> tleve...@gmail.com>> wrote:
>>>
>>>Any following on that?
>>>
>>>Daniel, have you been able to solve your problem? Did you wrote
>>>your own
>>>behavior?
>>>
>>>I have the same requirement as you and I am trying to find a quick
>>>way to
>>>solve my problem.
>>>
>>>Can someone point me to some examples on how to write my own Ajax
>>>behavior?
>>>
>>>Thanks
>>>
>>>Thierry
>>>
>>>
>>>On Tue, Jun 2, 2009 at 12:21, Igor Vaynberg
>>>mailto:igor.vaynb...@gmail.com>> wrote:
>>>
>>>> well, if you do not want to *submit* the form then dont use
>>>> ajaxformSUBMITbehavior :)
>>>>
>>>> with little work you can roll your own behavior that does a simple
>>>> ajax get and appends whatever values you need from formcomponents
>>> to
>>>> the url. that way the form is not submitted and you have access
>>>to the
>>>> raw values.
>>>>
>>>> -igor
>>>>
>>>>
>>>>
>>>> On Tue, Jun 2, 2009 at 9:16 AM, dfernandez
>>>> >>> wrote:
>>>> >
>>>> >
>>>> > Yes, I know it is tricky, but the fact is I don't think I
>>>would really
>>>> need
>>>> > type conversion in this case.
>>>> >
>>>> > I will try to explain myself. I have the following UI:
>>>> >
>>>> >|OPERATOR |V|
>>>> >
>>>> >|INPUT1="aBc"| |INPUT2="DeF"  |
>>>> >
>>>> > ...being "OPERATOR" the DropDownChoice, and both INPUT1 and
>>>INPUT2 two
>>>> > TextFields (String TextFields, to be precise). Both INPUT1 and
>>>INPUT2 are
>>>> > required (when they are visible, of course).
>>>> >
>>>> > When I change the value on "OPERATOR", the UI will change,
>>>hiding INPUT1
>>>> and
>>>> > INPUT2 but showing INPUT3, another TextField which should have
>>>the same
>>>> > contents that were on INPUT1 before:
>>>> >
>>>> >|OPERATOR |V|
>>>> >
>>>> >|INPUT3="aBc"|
>>>> >
>>>> > The problem is that, when changing OPERATOR, I need to read
>>>the value
>>>> from
>>>> > INPUT1 to set it into INPUT3, but if INPUT2 is empty I will
>>>receive a
>>>> > validation message telling me that it is required... which it
>>>is, but I
>>>> just
>>>> > want Wicket to validate that when I want to *really* submit
>>>the form, and
>>>> > not now that I am only changing the operator.
>>>> >
>>>> > Thanks.
>>>> >
>>>> > Regards,
>>>> > Daniel.
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > igor.vaynberg wrote:
>>>> >>
>>>> >> how are you planning on reading the other values? you cannot
>>>access
>>>> >> the model so you will have to call getinput(), are you also
>>>planning
>>>> >> on doing type conversion yourself then?
>>>> >>
>>>> >> -igor
>>>> >>
>>>> >> 2009/6/2 Daniel Fernández >>>:
>>>
>>>> >>> Hello,
>>>> >>>
>>>> >>> I have a form with a DropDownChoice, on which "onchange"
>>>event I want
>>>> to
>>>> >>> update some form components. But I need to read data from
>>>other fields
>>>> of
>>>> >>> the form for doing so, and so I added an
>>>AjaxFormSubmitBehavior to the
>>>> >>> DropDownChoice.
>>>> >>>
>>>> >>> My intention is to read the data from the drop dow

Re: How to turn ModalWindow form into multipart form?

[Vladimir K]

Eyal,

did you mean you have patched wicket.jar with modal.js on your own? I'm
going to omit patching wicket.jar.

We'll replace ModalWindow with regular page for a while. I don't understand
why ModalWindow hasn't been implemented with regular wicket ajax engine. It
would be easier to fix something.

Matej,

are you going to fix ModalWindow somehow to be capable of taking
FileUploadField and UploadProgressBar components?


egolan74 wrote:
> 
> we overridden modal.js and changed the appearance of the modal window
> 
> Eyal Golan
> egola...@gmail.com
> 
> Visit: http://jvdrums.sourceforge.net/
> LinkedIn: http://www.linkedin.com/in/egolan74
> 
> P  Save a tree. Please don't print this e-mail unless it's really
> necessary
> 
> 
> On Fri, Jun 26, 2009 at 11:49 AM, Vladimir K  wrote:
> 
>>
>> yes it do has.
>>
>> near line 1095 of modal.js:
>>
>> Wicket.Window.getMarkup = function(idWindow, idClassElement, idCaption,
>> idContent, idTop, idTopLeft, idTopRight, idLeft, idRight, idBottomLeft,
>> idBottomRight, idBottom, idCaptionText, isFrame) {
>>var s =
>>"> style=\"top: 10px; left:
>> 10px; width: 100px;\">>
>> style='background-color:transparent;padding:0px;margin:0px;border-width:0px;position:static'>"+
>>""+
>>
>> And it seems hacky and buggy.
>>
>> In our case we would use regular submit for FileUploadField instead of
>> ajax
>> if it wasn't hardcoded. Now we need to hack ModalWindow some way. I don't
>> like iframe approach 'cause it forces user to submit twice at the time
>> when
>> regular submit should have worked.
>>
>> If you don't know this very hardcoded form leads to problem reflecting
>> request parameters to form components models because in java we have a
>> stack
>> of forms and submit request contains just data of this particular form.
>> As
>> the result form components of enclosing forms receive empty data and then
>> ... at least unexpected validation problems.
>> There has been a jira issue already that contains workaround description.
>> I
>> have to go right now. I'll find it later.
>>
>>
>> igor.vaynberg wrote:
>> >
>> > modalwindow has a hardcoded form?
>> >
>> >
>> > On Thu, Jun 25, 2009 at 8:00 AM, Vladimir Kovalyuk
>> > wrote:
>> >> How to turn ModalWindow form into multipart form?
>> >> The problem is that the markup code for that particular form is
>> >> hard-coded
>> >> into modal.js script (surprise!, surprise!).
>> >>
>> >> ModalWindow form submission problems han't been fixed yet, I mean rc5
>> >>
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/How-to-turn-ModalWindow-form-into-multipart-form--tp24204896p24216939.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> 
> -
> Eyal Golan
> egola...@gmail.com
> 
> Visit: JVDrums 
> LinkedIn: LinkedIn 
> 

-- 
View this message in context: 
http://www.nabble.com/How-to-turn-ModalWindow-form-into-multipart-form--tp24204896p24273227.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: How to turn ModalWindow form into multipart form?

[Vladimir K]

yes it do has.

near line 1095 of modal.js:

Wicket.Window.getMarkup = function(idWindow, idClassElement, idCaption,
idContent, idTop, idTopLeft, idTopRight, idLeft, idRight, idBottomLeft,
idBottomRight, idBottom, idCaptionText, isFrame) {
var s =
""+
""+

And it seems hacky and buggy.

In our case we would use regular submit for FileUploadField instead of ajax
if it wasn't hardcoded. Now we need to hack ModalWindow some way. I don't
like iframe approach 'cause it forces user to submit twice and regular
submit should have worked.

If you don't know this very hardcoded form leads to problem reflecting
request parameters to form components models because in java we have a stack
of forms and submit request contains just data of this particular form. As
the result form components of enclosing forms receive empty data and then
... at least unexpected validation problems.
There has been a jira issue already that contains workaround description. I
have to go right now. I'll find it later.


igor.vaynberg wrote:
> 
> modalwindow has a hardcoded form?
> 
> 
> On Thu, Jun 25, 2009 at 8:00 AM, Vladimir Kovalyuk
> wrote:
>> How to turn ModalWindow form into multipart form?
>> The problem is that the markup code for that particular form is
>> hard-coded
>> into modal.js script (surprise!, surprise!).
>>
>> ModalWindow form submission problems han't been fixed yet, I mean rc5
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/How-to-turn-ModalWindow-form-into-multipart-form--tp24204896p24216939.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: how to split application properties file into several properties files

[Vladimir K]

As usual it becomes pretty simple if you know how.

in the init method you should add:

getResourceSettings().addStringResourceLoader(new
ClassStringResourceLoader(YourModule.class));

If ClassStringResourceLoader didn't called base class it would be more
efficient implementation.


Vladimir K wrote:
> 
> I would like to split the application properties file into several
> properties files.
> I know that I can share resources of base component and page among their
> descendants and at that I can use package propeties files. I just don't
> want
> to go this way because most of messages are organized in different way
> than
> components and pages.
> I wanna just split one file into several distinct files.
> 
> What is the best way?
> 
> 

-- 
View this message in context: 
http://www.nabble.com/how-to-split-application-properties-file-into-several-properties--files-tp24121864p24143617.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Time Field

[Vladimir K]

Does anyone know the converter for org.joda.time.Duration?
It is not trivial one taking into account the user's locale.
-- 
View this message in context: 
http://www.nabble.com/Time-Field-tp23930465p23931514.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Tools for Managing a Wicket Project

[Vladimir K]

I installed it on MyEclipse I didn't find how to format the text. Does it
capable to format text better than WTP does?


Linkan wrote:
> 
> We use Aptana plugin for eclipse as html editor. If you dont install the 
> full suit its free.
> 
> //Swanthe
> 
> Eduardo Nunes wrote:
>> I have just one problem with eclipse, I can't use the HTML formatter,
>> that's very sucks. I tried tidy but it didn't work too. What do you
>> use guys to format html code?
>>
>> On Mon, May 18, 2009 at 2:06 PM, Dane Laverty 
>> wrote:
>>   
>>> I just wanted to thank Jeremy, Scott, and Linda for recommending
>>> Effective
>>> Java. I read through the book this week. It's wonderful -- accessible
>>> and
>>> useful. Now I'm in the process of refactoring my project to start
>>> applying
>>> the concepts.
>>>
>>> On Fri, May 1, 2009 at 8:53 AM, Carlo Camerino 
>>> wrote:
>>>
>>> 
 we used to be bugzilla, mediawiki, continuum statck.we moved to Trac.
 It
 was
 simply amazing with all those plugins.

 Code Review WIth Trac Is Good.
 Review Board is also good software but it doesn't suit our programming
 needs.

 On Fri, May 1, 2009 at 11:38 PM, Matt Welch 
 wrote:

   
> Tools that our team is using (after some trial and error):
>
> IDE - Eclipse/IDEA
> Source Control - SVN
> Build - Maven
> Local Network Maven Repo - Nexus (after a year trying different ones)
> Build Server  - TeamCity, which absolutely rocks (We actually
> purchased
> 
 and
   
> used Bamboo for 9 months. I can't believe it comes from the same
> company
> 
 as
   
> JIRA. Bamboo was terrible.)
> Story Mgmt/Defects - Rally (hosted commercial app for agile projects;
> not
> bad, but not fantastic either)
> Code Review - Code Collaborator (again not bad and I'd rather have it
> 
 than
   
> nothing at all, but could be better)
>
>
> Our QA team has used various testing tools from expensive commercial
> 
 tools
   
> like Mercury (now HP) Quality Center to Selenium. They use Rally for
> 
 defect
   
> management.
>
> My highest recommendations are for TeamCity, Nexus, and SVN.
>
> -Matt
>
>
> --
> View this message in context:
>
> 
 http://www.nabble.com/Tools-for-Managing-a-Wicket-Project-tp23299396p23334970.html
   
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
> 
>>
>>
>>
>>   
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Tools-for-Managing-a-Wicket-Project-tp23299396p23647597.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: AW: How to validate unique constraint?

[Vladimir K]

Hibernate Validator is useful for bean validations but it has nothing to do
with unique constraint for which you should consult database unless you
cache all the instances.

I would like to provide user with an early warning that the data it fills in
is not unique but I haven't found solution out of the box that uses entity
annotations, especially UniqueContraint.


Dorothée Giernoth wrote:
> 
> 
> 
> I would find this very useful! So a contribution to wicket-stuff would be
> awesome. Thnx.
> 
> - dg
>  
> -Ursprüngliche Nachricht-
> Von: Clint Popetz [mailto:cl...@42lines.net] 
> Gesendet: Dienstag, 19. Mai 2009 13:49
> An: users@wicket.apache.org
> Betreff: Re: How to validate unique constraint?
> 
> It's relatively straightforward to use the hibernate validator api to
> apply JPA constraints:
> 
> import org.hibernate.validator.*;
> InvalidValue[] invalidValues = new
> ClassValidator(MyModel.class).getInvalidValues(instanceOfMyModel);
> 
> This can also be done per-property; see the javadocs.
> 
> I've done this locally; if folks would find it useful I'll contribute
> it to wicketstuff.
> 
> -Clint
> 
> On Tue, May 19, 2009 at 2:15 AM, Christian Helmbold
>  wrote:
>>
>> How can I validate a unique constraint with Wicket? Because only the
>> value of an input field is passed to onValidate(IValidatable
>> validatable), there is no chance to check if this value belongs to a
>> specific object to update or if it would violate a unique constraint when
>> creating a new object. onValidate would need another paremeter for the
>> related object.
>>
>> I see two possibilities:
>>
>> a) Use a form validator and get the related model object from the form.
>>
>> b) Pass the related object to the constructor of the Validator. I'm not
>> sure, if the validator would be recreated any time the model object
>> changes.
>>
>> I would prefer a validator tied to the field and not to the form, because
>> that would be more intuitive.
>>
>> Another idea is to use existing JPA annotations. @Column(unique=true) is
>> already there but not used for validation (outside the database). Perhaps
>> there is a way to use this annotation. I really like the domain level
>> validation of Grails:
>> http://grails.org/doc/1.1/guide/7.%20Validation.html
>>
>> How would you validate a unique constraint with wicket?
>>
>> Thanks in advance
>> Christian
>>
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> 
> 
> -- 
> Clint Popetz
> http://42lines.net
> Scalable Web Application Development
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/How-to-validate-unique-constraint--tp23610946p23629304.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Tools for Managing a Wicket Project

[Vladimir K]

Innate markup formatting in WTP is awful. It splits all tags between lines.
I searched the web but didn't find information how to configure WTP. I
returned back to myeclipse.

How could WTP fans be ok with default formatting?


Eduardo Nunes wrote:
> 
> it's very strange, because if I hit ctrl+shift+f in some html code
> with WTP, the source code will be completely unwell formatted. I will
> try amateras plugin, thank you
> 
> On Mon, May 18, 2009 at 9:15 PM, John Armstrong 
> wrote:
>> I always have to do a 'Refresh' when changing the HTML. Its quite
>> painful..
>>
>> I tend to author the bulk of my html in an external editor that is
>> more suitable to the purpose and fast ( the eclipse validators are
>> painfully slow, particularly in Javascript intensive pages). Then I
>> tweak it in Eclipse and hit F5. A Lot.
>>
>> John-
>>
>> On Mon, May 18, 2009 at 5:03 PM, pete swulius  wrote:
>>> It appears that using external html editors causes sync issues.
>>>  Apparently
>>> eclipse doesn't monitor changes to the file system, except to warn you
>>> that
>>> it's out of sync.  I would love the know the truth of it as I could very
>>> well be missing something obvious.  In fact, I would bet that I am,
>>> considering that eclispe is so cool.
>>>
>>> I am currently using the Amateras plugin:
>>> http://amateras.sourceforge.jp/cgi-bin/fswiki_en/wiki.cgi?page=EclipseHTMLEditor.
>>>  I have no problems with it, but I use it only for the syntax coloring
>>> and
>>> the occasional content assist.
>>>
>>> --pete
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> 
> 
> -- 
> Eduardo S. Nunes
> http://e-nunes.com.br
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Tools-for-Managing-a-Wicket-Project-tp23299396p23611513.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: SV: Component creation and initialization

[Vladimir K]

>From my perspective the isVisible() case deserves generification. I know that
there is a task for Wicket 1.5. I mean after that we should write an article
in Wiki.


Wilhelmsen Tor Iver wrote:
> 
> Overriding methods like isVisible() is also a form of
> "hack" to postpone a property value to a later time (basically the
> component stops having a "real" property called visible since the setter
> modifies a variable that the getter does not care about).
> 

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


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

Re: Component creation and initialization

[Vladimir K]

If the question is ressurecting again and again then it is an evidence that
there is something to address and improve. At least Wicket does not have a
method with self-documented name which deffers component creation. As the
result people have to search (using different words) and they don't satisfy
with the result 'cause the topic is still looks open.

This list is quite active and I appreciate the answers of core developers.
Probably Wicket is so good because in addition to the devotion of talented
and capable people to implementation, they do hear what the users say
directly, not indirectly via support team.


Jeremy Thomerson-5 wrote:
> 
> I actually had to Google that one.  But, yes, that is the general
> consensus that I've seen.  If you wanted to write a page that showed
> the different ways that you mentioned, that would be fine.  It really
> just depends on if you really need lazy component creation, and then
> how you want to implement it.
> 
> --
> Jeremy Thomerson
> http://www.wickettraining.com
> 
> 
> 
> 
> On Fri, May 15, 2009 at 11:13 AM, Clint Popetz  wrote:
>> TMTOWTDI
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

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


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

Re: objectautocomplete on a form with CompoundPropertyModel

[Vladimir K]

Does it perform validation on form submit?



nino martinez wael wrote:
> 
> hmm true, I think it's because it's ajax and actually get set before
> the form are submited. I agree it would be nice if it acted exactly
> like normal form, but I guess the way it are now allows much more
> flexibility, however it should be possible to do the other aswell.
> 
> regards
> 
> 2009/5/14 Brill Pappin :
>> I'd actually rather it worked as expected and simply set the object on
>> the
>> model property :)
>> However, it's usable so I'll live with it.
>>
>> - brill
>>
>> On 13-May-09, at 3:10 PM, nino martinez wael wrote:
>>
>>> Yeah or just another way of thinking.. :)
>>>
>>> 2009/5/11 Brill Pappin :

 Thanks that worked... although its a bit of a pain in the behind :)

 - Brill Pappin

 On 11-May-09, at 6:55 AM, nino martinez wael wrote:

> You do something like this:
>
> // compound model
>       private final IModel cityModel = new
> PropertyModel(
>                       searchWrapper, "cityId");
>
>
>
>       builderCity
>                               .updateOnSelectionChange(new
> ObjectAutoCompleteSelectionChangeListener() {
>                                       public void
> selectionChanged(AjaxRequestTarget target,
>                                                       IModel
> model) {
>
>  cityModel.setObject(model.getObject());
>
>                                       }
>                               });
> So it does not update on submit, but instead onSelectionChange of the
> builder..
>
> 2009/5/11 Brill Pappin :
>>
>> I'm trying to use ObjectAutoComplete from wicketstuff on a form where
>> the
>> model is a CompoundPropertyModel.
>>
>> The auto compete field doesn't seem to be setting its value on the
>> form
>> model at all during a submit.
>>
>> I've looked at the examples for this component and not a single one
>> actually
>> includes the onSubmit implementation.
>> Is there something special i have to do with this component?
>>
>> - Brill Pappin
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>


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

-- 
View this message in context: 
http://www.nabble.com/objectautocomplete-on-a-form-with-CompoundPropertyModel-tp23477130p23582308.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Component creation and initialization

[Vladimir K]

The horse is pretty alive -
https://issues.apache.org/jira/browse/WICKET-1134. 


Jeremy Thomerson-5 wrote:
> 
> With regards to multiple wicket:extend tags - that is also an old,
> dead horse that doesn't need to be beat right now.  The user list has
> a lot of discussion on it.  The simplest way to allow a child to
> contribute multiple components to a page is the same as you would do
> in normal java (which does not allow multiple inheritance) - expose
> multiple overridable methods that provide the components... i.e.:
> 

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


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

RE: May be useful for projects deciding between JSF and Wicket

[Vladimir K]

even more ... the title sounds a bit vulgarly.

But the arrangement of such links has a value itself. Especially for people
who hasn't started a project yet.

I would sort the list by date descending. The latest articles has more value
than older.


jeroend-2 wrote:
> 
> ...
> The title is subjective at best to start with and to open up with blog
> entries from 5 years ago is not giving it more credibility. ...
> 
> regards,
> jeroen.
> 

-- 
View this message in context: 
http://www.nabble.com/May-be-useful-for-projects-deciding-between-JSF-and-Wicket-tp23554009p23556062.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: May be useful for projects deciding between JSF and Wicket

[Vladimir K]

Where you were two years ago? :)


ptrthomas wrote:
> 
> Hi,
> 
> I blogged a fairly large collection of links to discussions about the
> issues
> with JSF in general.  What prompted me to put this up is that I yet again
> failed to convince a team at work that Wicket should be chosen over JSF.
> Frustrating.
> 
> Hope this proves useful to some, please pass it on to the pointy haired
> bosses, architecture astronauts, powerpoint consultants etc that you know.
> 
> DZone link:
> http://dzone.com/links/jsf_sucks_compendium_of_jsf_rantsreviews.html
> 
> Thanks,
> 
> Peter.
> 
> 

-- 
View this message in context: 
http://www.nabble.com/May-be-useful-for-projects-deciding-between-JSF-and-Wicket-tp23554009p23554709.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Component creation and initialization

[Vladimir K]

Igor,
I didn't mean spreading this approach everywhere :) My intention was to draw
your attention on that onBeforeRender probably is a good place to delay
construction but should be used with extra care and some sort of
simplification (more appropriate method) would be great.

You turned it insideout and it does not make sence anymore :)

Igor, Jeremy, thanks a lot for your suggestions. I have some food for my
brain to think about.


igor.vaynberg wrote:
> 
> by your own argument your own code will have to call your
> second-chance init constructor before invoking *any* method on the
> component.
> 
> so instead of
> 
> boolean visible=getMyComponent().isvisible();
> 
> you will have to now do
> 
> Component c=getMyComponent();
> if (!c.isinitted()) {c.initI(); }
> boolean visible=c.isvisible();
> 
> that init line is now necessary because you *never* know if a
> component has been initialized, so every access to any component
> memeber has to be prefixed by that init check. that will be fun! or we
> can just use constructors since thats what they are designed to do
> (its in the name)
> 
> -igor
> 
> On Thu, May 14, 2009 at 10:21 PM, Vladimir K  wrote:
>>
>> it has just come to my mind 
>>
>> I'm afraid Wicket can't guarantee that onBeforeRender would be called in
>> any
>> case. So there could be a case (isVisible() for instance) when
>> onBeforeRender is not called yet but overriding method could read
>> yet-not-completely-initialized object state.
>>
>> Instead of thinking how to work around isVisible() and the other cases
>> why
>> not just add a second-chance method and invoke it in appropriate places.
>>
>> in Component:
>>
>> boolean complete = false;
>> void ensureCompletelyInitialized() {
>>    if(!complete){
>>        finalizeCreation();
>>        complete = true;
>>    }
>> }
>>
>> void internalBeforeRender() {
>>    ensureCompletelyInitialized();
>>    ...
>> }
>>
>> I believe it makes sence.
>>
>>
>> Martijn Dashorst wrote:
>>>
>>> This has been discussed till death previously and we have excluded it
>>> from our roadmap. We will never have an init() method for components.
>>> Gossling gave us a Constructor to initialize your Objects.
>>>
>>> Search and read the archives if you want more information on the
>>> subject.
>>>
>>> Martijn
>>>
>>> On Fri, May 15, 2009 at 12:36 AM, Juan G. Arias 
>>> wrote:
>>>> It would be very nice to add a new phase for component creation, like I
>>>> said, an init() or createContent().
>>>> Is there a JIRA issue for that?
>>>> If yes, I will vote for it and suggest to change the name to something
>>>> _not_
>>>> related to the rendre phase.
>>>>
>>>> Thanks!
>>>> Juan
>>>>
>>>>
>>>> On Thu, May 14, 2009 at 3:31 PM, Daniel Stoch
>>>> wrote:
>>>>
>>>>> I think you can use hasBeenRendered() method instead of custom boolean
>>>>> flag.
>>>>>
>>>>> --
>>>>> Daniel
>>>>>
>>>>> On 2009-05-14, at 20:15, Jeremy Thomerson wrote:
>>>>>
>>>>>  You could probably do it in onBeforeRender - but you would need to
>>>>>> keep a boolean flag to check if it's the first render so that you
>>>>>> don't recreate them on a second render  There was talking of
>>>>>> adding an onBeforeFirstRender method, but I don't think it's happened
>>>>>> yet - you could look for the method to see if I'm wrong.
>>>>>>
>>>>>> --
>>>>>> Jeremy Thomerson
>>>>>> http://www.wickettraining.com
>>>>>>
>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>> Apache Wicket 1.3.5 is released
>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>
>>> -
>>> To unsubscribe, e-mail

Re: Component creation and initialization

[Vladimir K]

I'm doing just right like you described. Probably I have to pay more
attention to your comment about improper use of models. isVisible method
should rely only on the component model. I some cases it is easier to
delegate some calls to aggregated components. But instead I have to work
with component own model itself.


Jeremy Thomerson-5 wrote:
> 
> expose multiple overridable methods that provide the components... i.e.:
> 
> // I don't have my IDE open, so some method names may be wrong
> ParentComponent  {
> 
>   public void onBeforeRender {
> if (!hasBeenRendered()) {
>   add(createLeftNavPanel(getModel()));
>   add(createContentPanel(getModel()));
>   add(createTopHeaderPanel(getModel()));
> }
> 
> protected Component createContentPanel(IModel model) {
>   // this can be overridden in subclasses
>   return MyDefaultTypeOfContentPanel(model);
> }
> }
> 
> --
> Jeremy Thomerson
> http://www.wickettraining.com
> 
> 
> 
> 
> On Fri, May 15, 2009 at 12:54 AM, Vladimir K  wrote:
>>
>> Jeremy,
>>
>> I can't add another example to mentioned RepeatingView.
>> Concerning RepeatingView... Wicket allow me just one point to subclass
>> parent component markup within  tag. RepeatingView comes
>> in
>> handy. It allows me to reserve some places in base component markup and
>> put
>> something there in subclasssing component markup. I saw examples of that
>> in
>> some projects when studying Wicket. So I just copy the idea without
>> thinking
>> about WHEN to call the overridden method that fills in the RepeatingView
>> instance. It is my fault :)
>>
>> If you add "name" attribute to wicket:child tag, and multiple
>> > name="..."> tags I would use it instead of RepeatingView.
>>
>> Concerning your post on onBeforeRender ... I didn't say that it is
>> related
>> to class' constructor. Yes it is related to delayed component creation.
>> And
>> the reason why I delay creation is to follow mentioned rule. It is not
>> related to use of models in my case. I delay creation to allow
>> subclassing
>> components to replace some default parts of base component. Probably I'm
>> doing something wrong. Then suggest me how to do it right. For instance I
>> would like to subclass NatigationToolbar in DefaultDataTable. What should
>> I
>> do?
>>
>>
>> Jeremy Thomerson-5 wrote:
>>>
>>> Do you have any examples of where Wicket calls an overridable method
>>> from the constructor of a Wicket class?  If so, please file it as a
>>> JIRA - that would be a bug.
>>>
>>> Most java programmers know not to call overridable methods from the
>>> constructor as a general rule, although there are times when it could
>>> inadvertantly happen - which is why we need bug reports if you see
>>> that happening.
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>>
>>>
>>>
>>> On Fri, May 15, 2009 at 12:01 AM, Vladimir K  wrote:
>>>>
>>>> Martijn,
>>>>
>>>> here Java is not safe as a language. Yo're able to invoke overrided
>>>> methods
>>>> on non-completely constructed objects.
>>>>
>>>> from my perspective it is a regular case in Wicket:
>>>>
>>>> class SampleComponent extends ... {
>>>>    String parameter;
>>>>
>>>>    SampleComponent(String id, String parameter) {
>>>>        super(id);
>>>>        this.parameter = parameter;
>>>>    }
>>>>
>>>>    // method is called from within superconstructor
>>>>   �...@override
>>>>    void createAdditionalComponents(RepeatingView rv) {
>>>>        useSomehow(parameter);
>>>>    }
>>>> }
>>>>
>>>> I know two approaches to work around:
>>>> - onBeforeRender
>>>> - a closure as a constructor formal parameter.
>>>>
>>>> But the latter does not help with built-in components.
>>>>
>>>> If Wicket does not help us with adding appropriate method for
>>>> second-step-initialization it should document it in wiki, javadoc and
>>>> books
>>>> "dear user, when overriding methods, beware using of yet unassigned
>>>> constructor parameters". Hmm ... sounds stupid :)
>>>>
>>>>
>>>> Martijn Dashorst 

Re: Component creation and initialization

[Vladimir K]

Jeremy,

I can't add another example to mentioned RepeatingView.
Concerning RepeatingView... Wicket allow me just one point to subclass
parent component markup within  tag. RepeatingView comes in
handy. It allows me to reserve some places in base component markup and put
something there in subclasssing component markup. I saw examples of that in
some projects when studying Wicket. So I just copy the idea without thinking
about WHEN to call the overridden method that fills in the RepeatingView
instance. It is my fault :)

If you add "name" attribute to wicket:child tag, and multiple  tags I would use it instead of RepeatingView.

Concerning your post on onBeforeRender ... I didn't say that it is related
to class' constructor. Yes it is related to delayed component creation. And
the reason why I delay creation is to follow mentioned rule. It is not
related to use of models in my case. I delay creation to allow subclassing
components to replace some default parts of base component. Probably I'm
doing something wrong. Then suggest me how to do it right. For instance I
would like to subclass NatigationToolbar in DefaultDataTable. What should I
do?


Jeremy Thomerson-5 wrote:
> 
> Do you have any examples of where Wicket calls an overridable method
> from the constructor of a Wicket class?  If so, please file it as a
> JIRA - that would be a bug.
> 
> Most java programmers know not to call overridable methods from the
> constructor as a general rule, although there are times when it could
> inadvertantly happen - which is why we need bug reports if you see
> that happening.
> 
> --
> Jeremy Thomerson
> http://www.wickettraining.com
> 
> 
> 
> 
> On Fri, May 15, 2009 at 12:01 AM, Vladimir K  wrote:
>>
>> Martijn,
>>
>> here Java is not safe as a language. Yo're able to invoke overrided
>> methods
>> on non-completely constructed objects.
>>
>> from my perspective it is a regular case in Wicket:
>>
>> class SampleComponent extends ... {
>>    String parameter;
>>
>>    SampleComponent(String id, String parameter) {
>>        super(id);
>>        this.parameter = parameter;
>>    }
>>
>>    // method is called from within superconstructor
>>   �...@override
>>    void createAdditionalComponents(RepeatingView rv) {
>>        useSomehow(parameter);
>>    }
>> }
>>
>> I know two approaches to work around:
>> - onBeforeRender
>> - a closure as a constructor formal parameter.
>>
>> But the latter does not help with built-in components.
>>
>> If Wicket does not help us with adding appropriate method for
>> second-step-initialization it should document it in wiki, javadoc and
>> books
>> "dear user, when overriding methods, beware using of yet unassigned
>> constructor parameters". Hmm ... sounds stupid :)
>>
>>
>> Martijn Dashorst wrote:
>>>
>>> This has been discussed till death previously and we have excluded it
>>> from our roadmap. We will never have an init() method for components.
>>> Gossling gave us a Constructor to initialize your Objects.
>>>
>>> Search and read the archives if you want more information on the
>>> subject.
>>>
>>> Martijn
>>>
>>> On Fri, May 15, 2009 at 12:36 AM, Juan G. Arias 
>>> wrote:
>>>> It would be very nice to add a new phase for component creation, like I
>>>> said, an init() or createContent().
>>>> Is there a JIRA issue for that?
>>>> If yes, I will vote for it and suggest to change the name to something
>>>> _not_
>>>> related to the rendre phase.
>>>>
>>>> Thanks!
>>>> Juan
>>>>
>>>>
>>>> On Thu, May 14, 2009 at 3:31 PM, Daniel Stoch
>>>> wrote:
>>>>
>>>>> I think you can use hasBeenRendered() method instead of custom boolean
>>>>> flag.
>>>>>
>>>>> --
>>>>> Daniel
>>>>>
>>>>> On 2009-05-14, at 20:15, Jeremy Thomerson wrote:
>>>>>
>>>>>  You could probably do it in onBeforeRender - but you would need to
>>>>>> keep a boolean flag to check if it's the first render so that you
>>>>>> don't recreate them on a second render  There was talking of
>>>>>> adding an onBeforeFirstRender method, but I don't think it's happened
>>>>>> yet - you could look for the method to see if I'm wrong.
>>>>>>
>>>>>> --
>>>>>>

Re: Component creation and initialization

[Vladimir K]

it has just come to my mind 

I'm afraid Wicket can't guarantee that onBeforeRender would be called in any
case. So there could be a case (isVisible() for instance) when
onBeforeRender is not called yet but overriding method could read
yet-not-completely-initialized object state.

Instead of thinking how to work around isVisible() and the other cases why
not just add a second-chance method and invoke it in appropriate places.

in Component:

boolean complete = false;
void ensureCompletelyInitialized() {
if(!complete){
finalizeCreation();
complete = true;
}
}

void internalBeforeRender() {
ensureCompletelyInitialized();
...
}

I believe it makes sence.


Martijn Dashorst wrote:
> 
> This has been discussed till death previously and we have excluded it
> from our roadmap. We will never have an init() method for components.
> Gossling gave us a Constructor to initialize your Objects.
> 
> Search and read the archives if you want more information on the subject.
> 
> Martijn
> 
> On Fri, May 15, 2009 at 12:36 AM, Juan G. Arias 
> wrote:
>> It would be very nice to add a new phase for component creation, like I
>> said, an init() or createContent().
>> Is there a JIRA issue for that?
>> If yes, I will vote for it and suggest to change the name to something
>> _not_
>> related to the rendre phase.
>>
>> Thanks!
>> Juan
>>
>>
>> On Thu, May 14, 2009 at 3:31 PM, Daniel Stoch
>> wrote:
>>
>>> I think you can use hasBeenRendered() method instead of custom boolean
>>> flag.
>>>
>>> --
>>> Daniel
>>>
>>> On 2009-05-14, at 20:15, Jeremy Thomerson wrote:
>>>
>>>  You could probably do it in onBeforeRender - but you would need to
 keep a boolean flag to check if it's the first render so that you
 don't recreate them on a second render  There was talking of
 adding an onBeforeFirstRender method, but I don't think it's happened
 yet - you could look for the method to see if I'm wrong.

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

>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
> 
> 
> 
> -- 
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.5 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

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


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

Re: Component creation and initialization

[Vladimir K]

Martijn,

here Java is not safe as a language. Yo're able to invoke overrided methods
on non-completely constructed objects.

from my perspective it is a regular case in Wicket:

class SampleComponent extends ... {
String parameter;

SampleComponent(String id, String parameter) {
super(id);
this.parameter = parameter;
}

// method is called from within superconstructor
@Override
void createAdditionalComponents(RepeatingView rv) {
useSomehow(parameter);
}
}

I know two approaches to work around:
- onBeforeRender 
- a closure as a constructor formal parameter.

But the latter does not help with built-in components.

If Wicket does not help us with adding appropriate method for
second-step-initialization it should document it in wiki, javadoc and books
"dear user, when overriding methods, beware using of yet unassigned
constructor parameters". Hmm ... sounds stupid :)


Martijn Dashorst wrote:
> 
> This has been discussed till death previously and we have excluded it
> from our roadmap. We will never have an init() method for components.
> Gossling gave us a Constructor to initialize your Objects.
> 
> Search and read the archives if you want more information on the subject.
> 
> Martijn
> 
> On Fri, May 15, 2009 at 12:36 AM, Juan G. Arias 
> wrote:
>> It would be very nice to add a new phase for component creation, like I
>> said, an init() or createContent().
>> Is there a JIRA issue for that?
>> If yes, I will vote for it and suggest to change the name to something
>> _not_
>> related to the rendre phase.
>>
>> Thanks!
>> Juan
>>
>>
>> On Thu, May 14, 2009 at 3:31 PM, Daniel Stoch
>> wrote:
>>
>>> I think you can use hasBeenRendered() method instead of custom boolean
>>> flag.
>>>
>>> --
>>> Daniel
>>>
>>> On 2009-05-14, at 20:15, Jeremy Thomerson wrote:
>>>
>>>  You could probably do it in onBeforeRender - but you would need to
 keep a boolean flag to check if it's the first render so that you
 don't recreate them on a second render  There was talking of
 adding an onBeforeFirstRender method, but I don't think it's happened
 yet - you could look for the method to see if I'm wrong.

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

>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
> 
> 
> 
> -- 
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.5 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

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


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

Re: AW: How to avoid code duplication on forms?

[Vladimir K]

Factory pattern is about Dependency Inversion Principle. You may use this
pattern to avoid dependency to concrete classes.

So the best way in your case is having Factory that constructs concrete
editors via subclassing. They work best together :)


Christian Helmbold-2 wrote:
> 
> 
> I think the difference between sub classing and static factory methods is
> a matter of taste in this case.
> 
> If I have many fields, I'd need many classes for them. So I'd group them
> in a sub package. In the case of factory methods I'd group the methods to
> create fields in a class instead of a package.
> 
> Subclass:
> 
> 1class UserEmailField extends TextField {
> 2  public UserEmailField(String id, IModel model) {
> 3super(id, model);
> 4setRequired(true);
> 5add(EmailAddressValidator.getInstance())
> 6add(UniqueValidator.unique(SystemUser.class, "email"));
> 7  }
> 8}
> 
> Factory method:
> 
> 1public static TextField emailTextField(String id){
> 2return (TextField) new TextField(id)
> 3.setRequired(true)
> 4.add(EmailAddressValidator.getInstance())
> 5.add(UniqueValidator.unique(SystemUser.class,
> "email"));
> 6}
> 
> Your answer shows me, that there is no dramatically simpler way to do
> this. If you ignore the two lines for factory class declaration factory
> methods are even a bit shorter. Or is there an advantage of sub classing
> that I have missed?
> 
> Regards,
> Christian
> 
> 
> 
> - Ursprüngliche Mail 
>> Von: Igor Vaynberg 
>> An: users@wicket.apache.org
>> Gesendet: Freitag, den 8. Mai 2009, 09:08:34 Uhr
>> Betreff: Re: How to avoid code duplication on forms?
>> 
>> much simpler
>> 
>> class UserEmailField extends TextField {
>>   public UserEmailField(String id, IModel model) {
>> super(id, model);
>> add(EmailAddressValidator.getInstance())
>> add(UniqueValidator.unique(SystemUser.class, "email"));
>>}
>> }
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/How-to-avoid-code-duplication-on-forms--tp23440920p23496309.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Add a ui lock page over the page while waiting for response

[Vladimir K]

The following works for me pretty well:

http://cwiki.apache.org/WICKET/generic-busy-indicator-for-both-ajax-and-non-ajax-submits.html
http://cwiki.apache.org/WICKET/generic-busy-indicator-for-both-ajax-and-non-ajax-submits.html
 


Matthias Keller wrote:
> 
> Hi
> 
> Thanks for the input. I now used wicketstuff-jquery and wrote a custom 
> behaviour which adds the code to my form.
> For later reference:
> public class UIBlockerBehaviour extends JQueryBehavior {
> private static final ResourceReference BLOCKUI_JS =
> new CompressedResourceReference(UIBlockerBehaviour.class, 
> "jquery.blockUI.js");
> 
> ...
> 

-- 
View this message in context: 
http://www.nabble.com/Add-a-ui-lock-page-over-the-page-while-waiting-for-response-tp23407195p23427935.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Editable select

[Vladimir K]

Thanks. I'll try AutoCompleteSettings.


James Carman-3 wrote:
> 
> Perhaps autocomplete?
> 
> On Thu, May 7, 2009 at 5:55 AM, Vladimir Kovalyuk 
> wrote:
>> Does anybody know any editable select wicket-component that supports
>> attaching 'onchange' AjaxFormComponentUpdatingBehavior?
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

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


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

Re: Wicket Offline Applications

[Vladimir K]

Agree, I mentioned already it depends on the nature of the application.
Anyway unless the bank pays you on time-and-material basis it is risky to
implement two modes application (for bank and for dev team).

Consider Java Web Start vs Gears.


Carlo Camerino wrote:
> 
> hmm, you have a point here.however, every requirement is different.
> 
> I know that it may sound weird, but still I believe that it depends on the
> nature of the application.
> There are lots of types of applications that banks use.
> Some I know would have to always have a central server managing it.
> 
> There are different types of Technical Architectures that we cater for in
> our applications.
> There are some applicationms that always require online mode regardless
> adn
> there are applications that the user just
> needs to be able to view customer information ,etc
> 
> 
> actually it's hard to decide here.
> on the downside, I heard that GWT consumes a lot of resources on the
> client
> side, it's also a consideration.
> 
> Failsafe servers are of course an option but again, the network is still a
> factor here.
> For example a very slow connection to the central server makes my
> productivity a lot less.
> Some places suffer from low bandwidth, unreliable networks, etc...
> 
> I saw the value of distributed or offline applications that uses
> synchronization.
> It will be harder for the developers of course sicne they have to cater to
> two modes.
> On Sun, May 3, 2009 at 1:55 PM, Vladimir K  wrote:
> 
>>
>> I would install failsafe cluster rather satisfying every client request
>> about
>> offline workability. You may end up implementing all the front-end and
>> middle-end features in offline mode :)
>>
>> I believe offline mode should be used with care. The email applications
>> are
>> by nature offline. If you are certain that what the user does is offline
>> by
>> nature - implement it. If you have concerns that it should be involved
>> into
>> transaction (I mean a bit wider meaning than DB transaction) - implement
>> it
>> online and think about fail-safe servers.
>>
>> Concerning front-end and middle-end, AFAIK, every unit of work is a
>> transaction which is done with multi-level authorization, including
>> business
>> authorization. You either implement all the authorization offline
>> (insecure
>> at all, and impossible in some cases) or defer authorization untill
>> online
>> mode (non-transactional). If a request of some client was satisfied (in
>> offline mode) and then hasn't passed online authorization (for instance
>> it
>> violates some limits which can be thruly calculated on the server side
>> only), you will have to call the client and tell him your appologises (or
>> not directly you, then the bank. but the bank will then call you and tell
>> you something awesome).
>>
>> Or just tell me the name of the bank. I will never become its client :)
>>
>>
>> Carlo Camerino wrote:
>> >
>> > it's not for the public to use. but rather for people within the banks.
>> > internal applications. sometimes central connection is not available.
>> >
>> > On Fri, May 1, 2009 at 9:37 PM, James Carman
>> > wrote:
>> >
>> >> Are you sure a banking application would be the right place for a
>> >> gears-based implementation?  Wouldn't it be kinda important to make
>> >> sure the main server knows where everything is, when money is
>> >> concerned?
>> >>
>> >> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino 
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > Is there any project which has Wicket And Google Gears Integration?
>> >> > Wicket has really done a lot of us in speeding up development time.
>> >> Coming
>> >> > from a struts we saw the power of Wicket in terms its reusability
>> and
>> >> i've
>> >> > noticed that
>> >> > wicket already did most of the tasks that we would have to manually
>> do
>> >> using
>> >> > struts application, like session timeouts, redirects, etc
>> >> >
>> >> >  One of our main concerns however are that clients
>> >> > are asking for our applications to be available even if the network
>> is
>> >> down
>> >> > or if the central server is down..
>> >> > Currently we implemented our applications in a distributed fashion
>> >> wherein
>> >> > 

Re: Wicket Offline Applications

[Vladimir K]

I would install failsafe cluster rather satisfying every client request about
offline workability. You may end up implementing all the front-end and
middle-end features in offline mode :)

I believe offline mode should be used with care. The email applications are
by nature offline. If you are certain that what the user does is offline by
nature - implement it. If you have concerns that it should be involved into
transaction (I mean a bit wider meaning than DB transaction) - implement it
online and think about fail-safe servers.

Concerning front-end and middle-end, AFAIK, every unit of work is a
transaction which is done with multi-level authorization, including business
authorization. You either implement all the authorization offline (insecure
at all, and impossible in some cases) or defer authorization untill online
mode (non-transactional). If a request of some client was satisfied (in
offline mode) and then hasn't passed online authorization (for instance it
violates some limits which can be thruly calculated on the server side
only), you will have to call the client and tell him your appologises (or
not directly you, then the bank. but the bank will then call you and tell
you something awesome).

Or just tell me the name of the bank. I will never become its client :)


Carlo Camerino wrote:
> 
> it's not for the public to use. but rather for people within the banks.
> internal applications. sometimes central connection is not available.
> 
> On Fri, May 1, 2009 at 9:37 PM, James Carman
> wrote:
> 
>> Are you sure a banking application would be the right place for a
>> gears-based implementation?  Wouldn't it be kinda important to make
>> sure the main server knows where everything is, when money is
>> concerned?
>>
>> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino 
>> wrote:
>> > Hi,
>> >
>> > Is there any project which has Wicket And Google Gears Integration?
>> > Wicket has really done a lot of us in speeding up development time.
>> Coming
>> > from a struts we saw the power of Wicket in terms its reusability and
>> i've
>> > noticed that
>> > wicket already did most of the tasks that we would have to manually do
>> using
>> > struts application, like session timeouts, redirects, etc
>> >
>> >  One of our main concerns however are that clients
>> > are asking for our applications to be available even if the network is
>> down
>> > or if the central server is down..
>> > Currently we implemented our applications in a distributed fashion
>> wherein
>> > every branch ( Remote Location)  has its own server.
>> > However, this has implications of cost and administration issues.
>> > However, if offline mode is enabled we can just begin syncing right.
>> >
>> > I think that Wicket WIth Google Gears Application will make it even
>> better .
>> >
>> >
>> > I think this is really a plus when it comes to marketing it to
>> customers.
>> > Most of the applications that we create our banking applications and
>> any
>> > downtime is costing our clients.
>> >
>> > Hopefully we can also do this to offload the central servers and to put
>> > processing into client machines.
>> >
>> > One large problem I see though is that most code wil have to be moved
>> to
>> the
>> > Browser Layer.
>> > I'm thinking of how to create a wicket application which is mostly run
>> by
>> > java classes work on the client side.
>> > Looks as if there will be a lot of code changes...
>> > I'm not really sure if it would be a totally different programming
>> model.
>> >
>> > Anyone out there tried to integrate Gears And Wicket
>> >
>> > Carlo
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> 

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


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

Re: confirm leave page when a page contains unsaved data

[Vladimir K]

I think the approach similar to one used in CheckGroup would work. I just
wondered if it has already been implemented.


Newgro wrote:
> 
> Vladimir Kovalyuk schrieb:
>> Do wicket has a generic approach to handling the following scenario?
>>
>> 1. user opens a page with details of some entity, for instance a user.
>> 2. user starts to type in fields
>> 3. user clicks some link, then she is informed that the form contains
>> unsaved data and asked to press "discard and proceed", "save and proceed"
>> or
>> "cancel".
>>
>>   
> Nope. How should wicket decide on that? It's business logic. And so you 
> have to present the dialog
> (modal window?) yourself. Alternatively you could an javascript alert.
> 
> Cheers
> Per
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/confirm-leave-page-when-a-page-contains-unsaved-data-tp23312432p23313202.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: ModalWindows...

[Vladimir K]

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

vote for it


nino martinez wael wrote:
> 
> Very true
> +1 for adding a overridable method
> 
> 2009/4/30 Vladimir K :
>>
>> put the following into the  section of your page:
>>
>>                
>>                        jQuery(document).ready(function(){
>>                                if (typeof Wicket != 'undefined' &&
>> Wicket.Window)
>>                                        Wicket.Window.unloadConfirmation =
>> false;
>>                        });
>>                
>>
>> I don't like this approach because it violateds incapsulation. It should
>> has
>> been implemented as overridable method of ModalWindow.
>>
>>
>> Vidhya Kailash wrote:
>>>
>>> 1. How do I disable the popup that comes on click inside the modal
>>> window:
>>> "Are you sure you want to navigate away from this page"?
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/ModalWindows...-tp23300556p23309702.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

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


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

Re: GWT-like

[Vladimir K]

Igor, I believe it is not so bad idea to embed third-party JS components with
ease (those who are capable to wrap existing div tag).

1. Wicket applications can be leveraged by many well designed and tested JS
components
2. It reduces hardware requirements and imroves scalability due to smaller
number of client-server roundtrips
3. There are the cases where it is better to design component is JS instead
of Java, for instance imagine full calendar component (like MS outlook has),
dynamic charts (including Gantt), rich text editor and so on. Even any
drill-down component (menu, panel) is better to design in JS.

Probably wicket should be capable of transferring js-component's client
state to backing server-side component when handling the client event.
Creating a hidden text input and serializing js-component state to it before
submit will work. Just for synchronization. Concerning events it seems we
just can use exising behaviors.

I believe wicket ui in most cases is as fast as ajaxy js ui because in both
cases we have to exchange some packages of data and access the database. And
there should be the cases where wicket is faster because it can just apply
innerHtml. JS has to parse the response and do something with dom.
But there are the cases like tab control as mentioned, where we don't need
server roundtrip to switch tabs. From the other hand we probably just need
to optimize existing AjaxTabbedPanel to allow the settings on tab
(ajax/static). Depending on this setting the appropriate links will be
rendered on the tab captions.

Concerning GWT ... just have a look at response times of Compiere 3.0 on
latest Google Chrome. On my 2.4Ghz desktop it takes about 7 seconds between
click on radio-button and see that selection is changed. GWT is out of the
scope.


igor.vaynberg wrote:
> 
> dont try to make wicket into gwt. if you want a fat client then use
> gwt, if you want a server-side app then use wicket.
> 
> -igor
> 
> On Wed, Apr 29, 2009 at 8:06 AM, kan  wrote:
>> Is there any easy way to make wicket applications like GWT? I mean to
>> make a "heavy client side", so it will allow easy manage data
>> pre-loading and requests (AJAX too) caching. The aim is to minimize
>> amount of web-server requests.
>> Say, I have several tabs on a page. Some tabs should have all data
>> pre-loaded and switched immediately (no requests to server). Some tabs
>> are "big", so they do an AJAX request for data, but only if a tab is
>> opened first time.
>>
>> --
>> WBR, kan.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

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


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

Re: ModalWindows...

[Vladimir K]

put the following into the  section of your page:


jQuery(document).ready(function(){
if (typeof Wicket != 'undefined' && 
Wicket.Window)
Wicket.Window.unloadConfirmation = 
false;
});


I don't like this approach because it violateds incapsulation. It should has
been implemented as overridable method of ModalWindow.


Vidhya Kailash wrote:
> 
> 1. How do I disable the popup that comes on click inside the modal window:
> "Are you sure you want to navigate away from this page"?
> 

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


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

Re: AW: AW: Tabbed Panel with bookmarkable links

[Vladimir K]

But it is also a bug in the TabbedPanel which should work well without tabs.


Christian Helmbold-2 wrote:
> 
> 
>> > What if you use two different tabbed panels on the same page?
> 
>> 
>> Good point! It doesn't work with two panels on the same page! I don't
>> know why 
>> and how to fix it.
> 
> It was a mistake in my test code, that lead to this error. I accidentally
> added the tabs of my second tabbed panel to the first one. Multiple
> BookmarkableTabbedPanels work fine now.
> 
> Regards
> Christian
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Tabbed-Panel-with-bookmarkable-links-tp22418170p23295407.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Possible to retrieve previous page from PageMap

[Vladimir K]

The requirements are inconsistent. It is impossible to bookmark the link
today and come to the page tomorrow. Unless it shoud be considered as a long
running transaction, in which case only page parameter works.


pixologe wrote:
> 
> In our current case we would need to display a specific info only if the
> user came from a specific page.
> We are using BookmarkablePageLink with mounts and are keen on keeping our
> URLs as clean as possible, thus we would like to avoid passing a page
> classname around with every request or similar. 
> 

-- 
View this message in context: 
http://www.nabble.com/Possible-to-retrieve-previous-page-from-PageMap-tp20861106p23291877.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Form values lost in combination of Forms plus ModalWindow

[Vladimir K]

Thanks for Martin Makundi suggestion. The following workaround works:

Replace your form in ModalWindow with

public class ModalWindowForm extends Form {
public ModalWindowForm(String id) {
super(id);
}

@Override
public Form getRootForm() {
Form form = super.getRootForm();

if ((findParent(ModalWindow.class) != null) &&
(form.findParent(ModalWindow.class) == null))
return this;
else
return form;
}
}

What is not working is placing modal window form into another page form,
even a root form.


German Morales-3 wrote:
> 
> Hi again,
> 
> jira issue added:
>https://issues.apache.org/jira/browse/WICKET-1826
> 
> I've attached a quickstart project which shows my problem, has detailed
> explanation, and also proposes 2 solutions (you must uncomment some code
> to
> see it working). Of course, the solutions work for my particular case, but
> as you told me, it is not the way it is supposed to be.
> 
> Meanwhile (i guess it can take a while until someone looks into it), could
> you at least tell me if there could be any side effect in overriding
> isInputNullable for CheckBox, DropDownChoice, and so on? (TextField
> already
> does it).
> 
> Thanks again,
> 
> German
> 
> 
> 2008/9/10 Matej Knopp 
> 
>> On Wed, Sep 10, 2008 at 10:49 PM, German Morales
>>  wrote:
>> > I don't see any div inside span in my stuff (we have suffered problems
>> with
>> > this long ago, and we are more careful lately).
>> >
>> > Besides that, is it ok that the ModalWindow creates its own div at body
>> > level? Isn't that the reason of my problem?
>> That is intentional. I don't think that should cause you the problems.
>>
>> -Matej
>> >
>> > German
>> >
>> > 2008/9/10 Matej Knopp 
>> >
>> >> Check if your DOM hierarchy is valid, e.g. if you don't have any 
>> >> tag inside  tags.
>> >>
>> >> -Matej
>> >>
>> >> On Wed, Sep 10, 2008 at 10:08 PM, German Morales
>> >>  wrote:
>> >> > I think that we are closer to the problem now...
>> >> >
>> >> > In my case (going back to the original post), the form i'm
>> submitting
>> is
>> >> > inside a ModalWindow.
>> >> >
>> >> > I'm using Firebug to see the generated DOM in runtime, and i find
>> this
>> >> > (extracted...) before calling the ModalWindow:
>> >> >
>> >> > 
>> >> >   > window>
>> >> >  
>> >> >   
>> >> >   
>> >> > 
>> >> >
>> >> > after calling the modal window:
>> >> >
>> >> > 
>> >> >   > window>
>> >> >  
>> >> >   
>> >> >   
>> >> >   
>> >> >  
>> >> >   
>> >> > 
>> >> >
>> >> > I think that it's ok that the second form is rendered as form, since
>> it
>> >> does
>> >> > not have another form outside (to be rendered as div).
>> >> > The problem is that ModalWindow inserted a div outside my root form.
>> >> > Therefore Wicket.Form.serialize() must be serializing up to that
>> second
>> >> > form.
>> >> >
>> >> > I'm looking at the live Modal window example
>> >> > http://www.wicket-library.com/wicket-examples/ajax/modal-window.1
>> >> > and i see that this behavior of adding a separated div at body level
>> is
>> >> > "normal", not something strange in my structure.
>> >> >
>> >> > German
>> >> >
>> >> > 2008/9/10 Matej Knopp 
>> >> >
>> >> >> You are right. It calls Wicket.Form.serialize(form) with the nested
>> >> >> form, but the serialize method should find parent with  tag
>> name
>> >> >> and serialize that.
>> >> >>
>> >> >> -Matej
>> >> >>
>> >> >>
>> >> >> On Wed, Sep 10, 2008 at 9:04 PM, German Morales
>> >> >>  wrote:
>> >> >> > There are no nested form tags, as expected... let me give you
>> more
>> >> >> details
>> >> >> > i'm discovering:
>> >> >> >
>> >> >> > The AjaxSubmitLink has something like this...
>> >> >> >  function onclick(event) {
>> >> >> >   var wcall = wicketSubmitFormById(" < id of my nested form > ");
>> >> >> >   return false;
>> >> >> >  }
>> >> >> >
>> >> >> > This calls wicketSubmitFormById, no surprises...
>> >> >> >  function wicketSubmitFormById(formId, url, submitButton,
>> >> successHandler,
>> >> >> > failureHandler, precondition, channel) {
>> >> >> >   var call = new Wicket.Ajax.Call(url, successHandler,
>> failureHandler,
>> >> >> > channel);
>> >> >> >   ...
>> >> >> >   return call.submitFormById(formId, submitButton);
>> >> >> >  }
>> >> >> >
>> >> >> > which calls submitFormById...
>> >> >> >  submitFormById: function(formId, submitButton) {
>> >> >> >   var form = Wicket.$(formId);
>> >> >> >   ...
>> >> >> >   return this.submitForm(form, submitButton);
>> >> >> >  }
>> >> >> >
>> >> >> > which calls submitForm passing my nested form (i'm debugging with
>> >> >> Firebug)
>> >> >> >  // Submits a form using ajax.
>> >> >> >  // This method serializes a form and sends it as POST body.
>> >> >> >  submitForm: function(form, submitButton) {
>> >> >> >   var body = function() {
>> >> >> > var s = Wicket.Form.serialize(form);
>> >> >> > if (submitButton != nul

Re: Update DropDownChoice with ModalWindow

[Vladimir K]

The problem is duscussed here 
http://www.nabble.com/Form-values-lost-in-combination-of-Forms-plus-ModalWindow-td19401595.html#a19401595
http://www.nabble.com/Form-values-lost-in-combination-of-Forms-plus-ModalWindow-td19401595.html#a19401595
 


Vladimir K wrote:
> 
> PDiefent,
> 
> I've came across similar problem. In my case, and what I'm discovered fits
> your case as well, the following is happening:
> ...
> 

-- 
View this message in context: 
http://www.nabble.com/Update-DropDownChoice-with-ModalWindow-tp22595072p23274193.html
Sent from the Wicket - User mailing list archive at Nabble.com.

Re: Update DropDownChoice with ModalWindow

[Vladimir K]

PDiefent,

I've came across similar problem. In my case, and what I'm discovered fits
your case as well, the following is happening:

ModalWindow is component based. It is rendered in two parts. The first part
is all you put into your markup. The second part is dynamically built within
a separate div within the  tag.

Concerning browser's DOM, your form and modal window form are not
overlapped. Nothing is passed for DDChoice when modal window form is
submitted.
Concerning wicket tree your form and modal window form are overlapped (modal
form is within). So when wicket is updating formcomponent models (and it
starts from the outermost form for some reason), it has to fill DDC, but
nothing is passed in request for it. So wicket fills it with null, what
explains "choose a value" message in it.

I don't know what is actually wrong - how wicket is processing form or
ModalWindow implementation that renders modal window somewhere outside of
the place you pointed. It is up to authors to decide.

I'm going to investigate workarounds. Will be back if suceed.


PDiefent wrote:
> 
> It's definitely not a hashCode/equals problem, because when the page is
> rendered, the initial value of the dropDown is set correctly from the
> PropertyModel. After coming back from the modal window the DropDownChoice
> can't set the new value ...
> 
> asfernandes wrote:
>> 
>>> Looks like lack of hashCode/equals implementation for the type used.
>>> I suffered from exactly problem as you initially described... But in my 
>>> case, however, equals() was implemented to always return false, and 
>>> DropDownChoice calls it. Perhaps, your problem is different, but I don't 
>>> know if it can happen due to different instances of objects created by 
>>> LoadableDetachableModel so you had to correctly override this method, or 
>>> is a totally different thing...
>>> 
>>> 
>>> Adriano
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Update-DropDownChoice-with-ModalWindow-tp22595072p23273638.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Performance Benchmarks

[Vladimir K]

Can wicket help with estimating page size in bytes? (or in cucumbers if the
size of a cucumber is defined). I would like to keep pages footprint in
session as short as possible.

P.S.
JSF certainly can be slower than DB, especially when you use Seam and SFSB
as a page backing bean. It is easy to understand if you know that you have
several approaches to improve DB performance, just hire DBA and understand
the lifecycles of your entities and put them into appropriate cache. From
the other hand with JSF you just can do NOTHING. Just get rid of JSF (in
favor of Wicket for instance). JSF is a perverted framework. It is like
Visual Basic for the Java Web applications. It is just for designing hotel
booking sites. 


uwe janner wrote:
> 
> we did a performance comparison between wicket and jsf in january, and for
> our usecases wicket was the clear winner (about factor 4). wicket was
> nearly
> as fast as our old struts implementation.
> btw, we used wicket together with seam, which also did not add much to the
> execution times.
> 
> uwe.
> 
> On Mon, Apr 27, 2009 at 3:49 AM, Peter Thomas  wrote:
> 
>> LOL at Jeremy's definitive quote :)
>>
>> Coming to original post - Munna: there is some comparative info on
>> performance and memory usage here:
>>
>>
>> http://ptrthomas.wordpress.com/2009/01/14/seam-jsf-vs-wicket-performance-comparison/
>>
>> Hope this helps.
>>
>> On Sun, Apr 26, 2009 at 7:26 PM, Jeremy Thomerson <
>> jer...@wickettraining.com
>> > wrote:
>>
>> > Does this count?
>> >
>> > "It's really fast" - quote from Jeremy Thomerson in his email written
>> > Sunday, April 26.
>> >
>> > Sorry - couldn't resist a little laugh.  I never put much faith in
>> > other people's "performance benchmarks" because they are typically
>> > little more than anecdotal evidence of their limited experience with X
>> > over Z.  But here's my anecdotal "benchmark" - I've never debugged an
>> > application where Wicket was the *slow* part of the application.  And
>> > I've debugged a lot of Wicket applications.  It's always the DB layer.
>> >  Occasionally something resource intensive in the service layer.  But
>> > always the DB layer.
>> >
>> > --
>> > Jeremy Thomerson
>> > http://www.wickettraining.com
>> >
>> >
>> >
>> >
>> > On Sun, Apr 26, 2009 at 8:09 PM, Munna Ramjee 
>> > wrote:
>> > > Hi All,
>> > > Are there any performance benchmarks posted anywhere for Wicket?
>> > > Thanks in advance for the help.
>> > >
>> > > Thanks,
>> > > Munna.
>> > >
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >
>> >
>>
> 
> 

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


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

Re: DefaultDataTable: How to add a DDChoice to change rows per page

[Vladimir K]

Vit, thanks for pointing the topic. It will come in handy.

However I believe it makes sense to have DDC incorporated into navigation
toolbar to save space.


Vit Rozkovec wrote:
> 
> Hi, check this out:
> http://www.nabble.com/nice-small-component-to-share-Toolbar-for-DataTable-to16743136.html
> 
> Vladimir Kovalyuk wrote:
>> I would like to add some component, say DropDownChoice, to allow user to
>> change default rows per page setting for data table.
>>
>> I've investigated two ways: 1) extend NavigationToolbar or
>> PagingNavigator
>> 2) extends NavigationToolbar to add extra panel right to PagingNavigator
>>
>> Althought it is possible to completely override PagingNavigator component
>> it
>> is not so straightforward as I expected.
>>
>> Please improve DefaultDataTable so it will be capable to change rows per
>> page.
>>
>> I also suggest creating child components in all the non-final components
>> via
>> createXXX methods instead of new keyword in order to simplify overriding.
>>
>>   
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/DefaultDataTable%3A-How-to-add-a-DDChoice-to-change-rows-per-page-tp23244335p23252333.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Adding components to Pages based on conditionals

[Vladimir K]

Try EmptyPanel component which is shipped with Wicket.

if (condition)
  add(new YourVisibleComponent("componentId"));
else
  add(new EmptyPanel("componentId"));

Do not forget about OOD. You can introduce createYourVisibleComponent()
method which creates empty panel in base class and some certain component in
derived classes.


subbu_tce wrote:
> 
> Hi,
> I am a new wicket user.
> How do we include / exclude content or components in pages based on
> conditions.
> What is the equivalent in Wicket to the if tag in the JSTL tag library?
> 
> The reason i ask this question is because irrespective of whether i add
> the
> component in the page, i need to have the markup for the component in the
> HTML.
> 
> Thanks in advance for the answers.
> 
> Thanks,
> Subbu.
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Adding-components-to-Pages-based-on-conditionals-tp23091567p23092032.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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