RE: Is it a bug that Enclosure is not invoking component resolver to resolve its children?
> to make the component a direct child of enclosure you would have to > have an Enclosure component that is explicitly added into the > hierarchy, at which point you can simply use a WebMarkupContainer > whose visibility is tied to that of the child to replicate the > functionality. the whole point of enclosure is that there is no > java-side component. Ok, well I'll drop that approach as an option. One thing I don't understand: [This question applies to any markup type/resolver pair I suppose] Is EnclosureResolver.resolve meant to be called to resolve the children of an Enclosure or to resolve the Enclosure itself? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Testing DataView
Hi All, I'm also going through the unit testing learning curve. Unfortunately, I didn't really understand the discussion about testing the DataView component. I just implemented my first DataView code, which is more or less a copy of the Wicket http://www.wicket-library.com/wicket-examples/repeater/;jsessionid=876AF7E1C1F6C0B7463DF0D4B1D4627A?wicket:bookmarkablePage=sources:org.apache.wicket.examples.source.SourcesPage&SourcesPage_class=org.apache.wicket.examples.repeater.SortingPage Sorting DataView example. Any further pointers on testing DataViews would be most welcome (BTW, I have been using EasyMock for integration testing). Thanks guys! -- View this message in context: http://www.nabble.com/Testing-DataView-tp21863271p25517641.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: rpc question
While you could use Wicket for this, personally I think you're getting close to viewing Wicket as the golden hammer :-) Why not use Jersey for instance. I just used that myself (in a project where the UI is in Wicket), and especially together with Jackson for JSON <--> Pojo serialization this seems to work pretty well. It's also part of a standard (JaxRS), which imho should never be the main reason to choose something, but is a nice little extra. Eelco 2009/9/18 Petr Kobalíček : > Thanks guys, > > the solution from Pedro > (http://blog.brunoborges.com.br/2008/11/restful-web-services-with-wicket.html) > is very close I talked about. I think that wicket supports to send > JSON instead of XML, so I'm going to play with this. > > I have another question, maybe very OT, can I connect this solution > with standard RPC server to check for types, etc? For example with > http://jabsorb.org/ ? I'd like to use wicket sessions and request > cycle with RPC services, or is my demand stupid (I mean that there are > better solutions)? > > My problem is that I have quite big application in qooxdoo that > communicates only through JSON (not strictly RPC). This is used for > administration part. And second part of application is pure wicket > solution. I'd like to stay with qooxdoo for administration, i like it. > > Cheers and thanks > - Petr > > 2009/9/18 Marc Ende : >> Hi Petr, >> >> sorry, I've misunderstood your mail... :) >> >> you've meant the other way round. May be you should try to >> build a restful webservice. It's also possible with wicket if you >> decide xml as a resultpage. >> >> For example: >> http://java.dzone.com/news/wicket-creating-restful-urls >> >> Am Fri, 18 Sep 2009 17:48:01 +0200 >> schrieb Marc Ende : >> >>> Hi Petr, >>> >>> I think you should use a LoadableDetachableModel. Within the method >>> load() you can execute your call to the webservice or other >>> remote-service. >>> >>> http://cwiki.apache.org/WICKET/working-with-wicket-models.html#WorkingwithWicketmodels-DetachableModels >>> >>> yours >>> marc >>> >>> Am Fri, 18 Sep 2009 14:20:27 + >>> schrieb Petr Kobalíček : >>> >>> > Hi list, >>> > >>> > is there a simple tutorial about making RPC services in wicket? I >>> > mean all integrated with wicket RequestCycle and Sessions, ideally >>> > that I can expose web services through some Wicket page like class. >>> > I'm porting one application and we have admin interface in qooxdoo >>> > toolkit (it communicates through json requests). >>> > >>> > I'd like to hear about "wicket" solution to this problem. >>> > >>> > Thanks for possibilities >>> > - Petr >>> > >>> > - >>> > 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
Re: Is it a bug that Enclosure is not invoking component resolver to resolve its children?
to make the component a direct child of enclosure you would have to
have an Enclosure component that is explicitly added into the
hierarchy, at which point you can simply use a WebMarkupContainer
whose visibility is tied to that of the child to replicate the
functionality. the whole point of enclosure is that there is no
java-side component.
-igor
On Fri, Sep 18, 2009 at 4:27 PM, Chris Colman
wrote:
>> > At what point in the lifecycle of normal parent should the component
>> resolver be invoked to instantiate the children?
>>
>> this happens during render time when wicket is trying to match up
>> markup to a component
>
> I'm wondering if Enclosure, with its need to obtain knowledge of its 'child'
> (which is really it's sibling!) is prematurely trying to reach its child
> (sibling) before the normal 'child component resolution' process has
> processed the child.
>
> Perhaps this wouldn't be a problem if the 'child' of an enclosure actually
> *was* a true child of the enclosure rather than being its sibling h.
>
> That might allow the Enclosure's own 'child resolution process' to work via
> the normal parent/child component resolution mechanism.
>
> In that case it might just work if the following line:
>
> final Component< ? > child = parent.get(childId.toString());
>
> was changed to
>
> final Component< ? > child = get(childId.toString());
>
> How do you feel about that approach?
>
> Regards,
> Chris
>
>>
>> > And... is there a convention for calling the component resolvers?
>> There's obviously a collection of them in the settings so does this need
>> to be iterated through until one returns 'true' or is there somewhere in
>> the framework where this iterating code can be called?
>>
>> as far as i rememember there is a collection registered in setttings
>> and then each component can also implement a resolver.
>>
>> the contract can be seen in markupcontainer#rendernext method
>> 1) first walk over the component hierarchy and check if any are resolvers
>> 2) walk over collection of resolvers in the settings
>>
>> as soon as true is returned from resolve iteration is stopped.
>>
>> this contract is not factored out anywhere, but maybe doing so may be
>> worthwhile. can be part of your patch, something like
>> ComponentResolvers.resolve(MarkupContainer parent, )
>>
>> hope this gets you started.
>> -igor
>>
>>
>>
>> >
>> > Regards,
>> > Chris
>> >
>> >>
>> >> On Thu, Sep 17, 2009 at 1:57 PM, Chris Colman
>> >> wrote:
>> >> > As can be seen by the Enclosure.getChildComponent method below the
>> >> > component resolver expects to find the 'child' within its own parent
>> -
>> >> > i.e. it assumes that its *child* is actually its sibling via:
>> >> >
>> >> > child = parent.get(childId.toString());
>> >> >
>> >> > While all other children of the common parent are resolved perfectly
>> by
>> >> > the component resolver the fact that the enclosure's child is not
>> really
>> >> > a child of the enclosure's parent (at least not in the markup) but
>> >> > rather a child of the enclosure itself seems to mean that the normal
>> >> > resolving mechanism that allowed all other 'siblings' to be
>> instantiated
>> >> > by my custom component resolver is bypassed.
>> >> >
>> >> > Is that a bug? If it is a bug is there something I can do to work
>> around
>> >> > this to make this 'child' get resolved like all the other children of
>> >> > the enclosure's parent? i.e. somehow cause my custom component
>> resolver
>> >> > to be invoke like it is for the other children.
>> >> >
>> >> >
>> >> >> public Component< ? > getChildComponent()
>> >> >> {
>> >> >> if (childComponent == null)
>> >> >> {
>> >> >> MarkupContainer< ? > parent =
>> >> >> getEnclosureParent();
>> >> >>
>> >> >> if (childId == null)
>> >> >> {
>> >> >> throw new MarkupException(
>> >> >> "You most likely forgot to
>> >> >> register the EnclosureHandler with the MarkupParserFactory");
>> >> >> }
>> >> >>
>> >> >> final Component< ? > child =
>> >> >> parent.get(childId.toString());
>> >> >> if (child == null)
>> >> >> {
>> >> >> throw new MarkupException(
>> >> >> "Didn't find child component
>> of
>> >> >> with id='" + childId +
>> >> >> "'. Component: " +
>> >> >> this.toString());
>> >> >> }
>> >> >> childComponent = child;
>> >> >> }
>> >> >> return childComponent;
>> >> >> }
>> >> >>
>> >> >>
>> -
>> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >> >> For additional commands, e-mail: users-h..
RE: Is it a bug that Enclosure is not invoking component resolver to resolve its children?
> > At what point in the lifecycle of normal parent should the component
> resolver be invoked to instantiate the children?
>
> this happens during render time when wicket is trying to match up
> markup to a component
I'm wondering if Enclosure, with its need to obtain knowledge of its 'child'
(which is really it's sibling!) is prematurely trying to reach its child
(sibling) before the normal 'child component resolution' process has processed
the child.
Perhaps this wouldn't be a problem if the 'child' of an enclosure actually
*was* a true child of the enclosure rather than being its sibling h.
That might allow the Enclosure's own 'child resolution process' to work via the
normal parent/child component resolution mechanism.
In that case it might just work if the following line:
final Component< ? > child = parent.get(childId.toString());
was changed to
final Component< ? > child = get(childId.toString());
How do you feel about that approach?
Regards,
Chris
>
> > And... is there a convention for calling the component resolvers?
> There's obviously a collection of them in the settings so does this need
> to be iterated through until one returns 'true' or is there somewhere in
> the framework where this iterating code can be called?
>
> as far as i rememember there is a collection registered in setttings
> and then each component can also implement a resolver.
>
> the contract can be seen in markupcontainer#rendernext method
> 1) first walk over the component hierarchy and check if any are resolvers
> 2) walk over collection of resolvers in the settings
>
> as soon as true is returned from resolve iteration is stopped.
>
> this contract is not factored out anywhere, but maybe doing so may be
> worthwhile. can be part of your patch, something like
> ComponentResolvers.resolve(MarkupContainer parent, )
>
> hope this gets you started.
> -igor
>
>
>
> >
> > Regards,
> > Chris
> >
> >>
> >> On Thu, Sep 17, 2009 at 1:57 PM, Chris Colman
> >> wrote:
> >> > As can be seen by the Enclosure.getChildComponent method below the
> >> > component resolver expects to find the 'child' within its own parent
> -
> >> > i.e. it assumes that its *child* is actually its sibling via:
> >> >
> >> > child = parent.get(childId.toString());
> >> >
> >> > While all other children of the common parent are resolved perfectly
> by
> >> > the component resolver the fact that the enclosure's child is not
> really
> >> > a child of the enclosure's parent (at least not in the markup) but
> >> > rather a child of the enclosure itself seems to mean that the normal
> >> > resolving mechanism that allowed all other 'siblings' to be
> instantiated
> >> > by my custom component resolver is bypassed.
> >> >
> >> > Is that a bug? If it is a bug is there something I can do to work
> around
> >> > this to make this 'child' get resolved like all the other children of
> >> > the enclosure's parent? i.e. somehow cause my custom component
> resolver
> >> > to be invoke like it is for the other children.
> >> >
> >> >
> >> >> public Component< ? > getChildComponent()
> >> >> {
> >> >> if (childComponent == null)
> >> >> {
> >> >> MarkupContainer< ? > parent =
> >> >> getEnclosureParent();
> >> >>
> >> >> if (childId == null)
> >> >> {
> >> >> throw new MarkupException(
> >> >> "You most likely forgot to
> >> >> register the EnclosureHandler with the MarkupParserFactory");
> >> >> }
> >> >>
> >> >> final Component< ? > child =
> >> >> parent.get(childId.toString());
> >> >> if (child == null)
> >> >> {
> >> >> throw new MarkupException(
> >> >> "Didn't find child component
> of
> >> >> with id='" + childId +
> >> >> "'. Component: " +
> >> >> this.toString());
> >> >> }
> >> >> childComponent = child;
> >> >> }
> >> >> return childComponent;
> >> >> }
> >> >>
> >> >>
> -
> >> >> 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
> >
> >
> > -
Re: Is it a bug that Enclosure is not invoking component resolver to resolve its children?
On Fri, Sep 18, 2009 at 3:02 PM, Chris Colman
wrote:
>> you are welcome to provide a patch.
>>
>> -igor
>
> I would if I could get it working ;).
>
> At what point in the lifecycle of normal parent should the component resolver
> be invoked to instantiate the children?
this happens during render time when wicket is trying to match up
markup to a component
> And... is there a convention for calling the component resolvers? There's
> obviously a collection of them in the settings so does this need to be
> iterated through until one returns 'true' or is there somewhere in the
> framework where this iterating code can be called?
as far as i rememember there is a collection registered in setttings
and then each component can also implement a resolver.
the contract can be seen in markupcontainer#rendernext method
1) first walk over the component hierarchy and check if any are resolvers
2) walk over collection of resolvers in the settings
as soon as true is returned from resolve iteration is stopped.
this contract is not factored out anywhere, but maybe doing so may be
worthwhile. can be part of your patch, something like
ComponentResolvers.resolve(MarkupContainer parent, )
hope this gets you started.
-igor
>
> Regards,
> Chris
>
>>
>> On Thu, Sep 17, 2009 at 1:57 PM, Chris Colman
>> wrote:
>> > As can be seen by the Enclosure.getChildComponent method below the
>> > component resolver expects to find the 'child' within its own parent -
>> > i.e. it assumes that its *child* is actually its sibling via:
>> >
>> > child = parent.get(childId.toString());
>> >
>> > While all other children of the common parent are resolved perfectly by
>> > the component resolver the fact that the enclosure's child is not really
>> > a child of the enclosure's parent (at least not in the markup) but
>> > rather a child of the enclosure itself seems to mean that the normal
>> > resolving mechanism that allowed all other 'siblings' to be instantiated
>> > by my custom component resolver is bypassed.
>> >
>> > Is that a bug? If it is a bug is there something I can do to work around
>> > this to make this 'child' get resolved like all the other children of
>> > the enclosure's parent? i.e. somehow cause my custom component resolver
>> > to be invoke like it is for the other children.
>> >
>> >
>> >> public Component< ? > getChildComponent()
>> >> {
>> >> if (childComponent == null)
>> >> {
>> >> MarkupContainer< ? > parent =
>> >> getEnclosureParent();
>> >>
>> >> if (childId == null)
>> >> {
>> >> throw new MarkupException(
>> >> "You most likely forgot to
>> >> register the EnclosureHandler with the MarkupParserFactory");
>> >> }
>> >>
>> >> final Component< ? > child =
>> >> parent.get(childId.toString());
>> >> if (child == null)
>> >> {
>> >> throw new MarkupException(
>> >> "Didn't find child component of
>> >> with id='" + childId +
>> >> "'. Component: " +
>> >> this.toString());
>> >> }
>> >> childComponent = child;
>> >> }
>> >> return childComponent;
>> >> }
>> >>
>> >> -
>> >> 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
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: rpc question
Thanks guys, the solution from Pedro (http://blog.brunoborges.com.br/2008/11/restful-web-services-with-wicket.html) is very close I talked about. I think that wicket supports to send JSON instead of XML, so I'm going to play with this. I have another question, maybe very OT, can I connect this solution with standard RPC server to check for types, etc? For example with http://jabsorb.org/ ? I'd like to use wicket sessions and request cycle with RPC services, or is my demand stupid (I mean that there are better solutions)? My problem is that I have quite big application in qooxdoo that communicates only through JSON (not strictly RPC). This is used for administration part. And second part of application is pure wicket solution. I'd like to stay with qooxdoo for administration, i like it. Cheers and thanks - Petr 2009/9/18 Marc Ende : > Hi Petr, > > sorry, I've misunderstood your mail... :) > > you've meant the other way round. May be you should try to > build a restful webservice. It's also possible with wicket if you > decide xml as a resultpage. > > For example: > http://java.dzone.com/news/wicket-creating-restful-urls > > Am Fri, 18 Sep 2009 17:48:01 +0200 > schrieb Marc Ende : > >> Hi Petr, >> >> I think you should use a LoadableDetachableModel. Within the method >> load() you can execute your call to the webservice or other >> remote-service. >> >> http://cwiki.apache.org/WICKET/working-with-wicket-models.html#WorkingwithWicketmodels-DetachableModels >> >> yours >> marc >> >> Am Fri, 18 Sep 2009 14:20:27 + >> schrieb Petr Kobalíček : >> >> > Hi list, >> > >> > is there a simple tutorial about making RPC services in wicket? I >> > mean all integrated with wicket RequestCycle and Sessions, ideally >> > that I can expose web services through some Wicket page like class. >> > I'm porting one application and we have admin interface in qooxdoo >> > toolkit (it communicates through json requests). >> > >> > I'd like to hear about "wicket" solution to this problem. >> > >> > Thanks for possibilities >> > - Petr >> > >> > - >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> > For additional commands, e-mail: users-h...@wicket.apache.org >> > > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Is it a bug that Enclosure is not invoking component resolver to resolve its children?
> you are welcome to provide a patch.
>
> -igor
I would if I could get it working ;).
At what point in the lifecycle of normal parent should the component resolver
be invoked to instantiate the children?
And... is there a convention for calling the component resolvers? There's
obviously a collection of them in the settings so does this need to be iterated
through until one returns 'true' or is there somewhere in the framework where
this iterating code can be called?
Regards,
Chris
>
> On Thu, Sep 17, 2009 at 1:57 PM, Chris Colman
> wrote:
> > As can be seen by the Enclosure.getChildComponent method below the
> > component resolver expects to find the 'child' within its own parent -
> > i.e. it assumes that its *child* is actually its sibling via:
> >
> > child = parent.get(childId.toString());
> >
> > While all other children of the common parent are resolved perfectly by
> > the component resolver the fact that the enclosure's child is not really
> > a child of the enclosure's parent (at least not in the markup) but
> > rather a child of the enclosure itself seems to mean that the normal
> > resolving mechanism that allowed all other 'siblings' to be instantiated
> > by my custom component resolver is bypassed.
> >
> > Is that a bug? If it is a bug is there something I can do to work around
> > this to make this 'child' get resolved like all the other children of
> > the enclosure's parent? i.e. somehow cause my custom component resolver
> > to be invoke like it is for the other children.
> >
> >
> >> public Component< ? > getChildComponent()
> >> {
> >> if (childComponent == null)
> >> {
> >> MarkupContainer< ? > parent =
> >> getEnclosureParent();
> >>
> >> if (childId == null)
> >> {
> >> throw new MarkupException(
> >> "You most likely forgot to
> >> register the EnclosureHandler with the MarkupParserFactory");
> >> }
> >>
> >> final Component< ? > child =
> >> parent.get(childId.toString());
> >> if (child == null)
> >> {
> >> throw new MarkupException(
> >> "Didn't find child component of
> >> with id='" + childId +
> >> "'. Component: " +
> >> this.toString());
> >> }
> >> childComponent = child;
> >> }
> >> return childComponent;
> >> }
> >>
> >> -
> >> 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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Update Tree Model on Ajax timer. What's wrong ?
Well Wicketstuuf is nice because we can find many wicket components in one place. I was not aware of your wicket-tree until today thanks to this post. I believe that projects in wicketstuff are not dependent to the wicket core/extension projet. Also I've got trouble with tortoiseSVN every time I tried to checkout a project from codegoogle! :-(( svenmeier wrote: > > Well, Sourceforge isn't the only place for projects. > IMHO some Wicket components (mainly in extensions) need a major overhaul > and new independent projects like wicket-tree can prove how things can > be solved differently (better?). > I'm just in progress of publishing another Wicket library and after that > I'm planning to tackle another headache. > > -- View this message in context: http://www.nabble.com/Update-Tree-Model-on-Ajax-timer.-What%27s-wrong---tp25468038p25515942.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: Update Tree Model on Ajax timer. What's wrong ?
> This wicket-tree seems really nice. Well done! Thanks - Wicket makes it really easy to build reusable components. > Why isn't it in wicketstuff? It may even replace the "headache" swing wicket-extension one (in 1.5?)... Well, Sourceforge isn't the only place for projects. IMHO some Wicket components (mainly in extensions) need a major overhaul and new independent projects like wicket-tree can prove how things can be solved differently (better?). I'm just in progress of publishing another Wicket library and after that I'm planning to tackle another headache. If 1.5 shall include a replacement for the current tree components, I'm the first to volunteer with a contribution. Regards Sven - 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
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.
>> >>>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.
Re: Bug with firefox when submitting an ajax form inside a modal window
yes he has to make it a form component... 2009/9/18 Sven Meier > > Hmm what exactly does that mean? > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Bug with firefox when submitting an ajax form inside a modal window
> Hmm what exactly does that mean? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: same data set shows for all users
I wouldn't say it's a bad practice, it just depends on how the objects are intended to be used. If you have mutable data specific to each user that must span several pages and shouldn't be messed with by other users than session is a good place, like you now have for your DB. But if there are things that should be shared among all users and components then application can be a good place for this, better than having singletons. Example with the app I'm working on how is that I put a few factory objects there that determine how certain pages, panels, and other components through the application should be created for all users. Craig -Original Message- From: Randy [mailto:ran...@goodsmillwork.com] Sent: Friday, September 18, 2009 9:37 AM To: users@wicket.apache.org Subject: RE: same data set shows for all users I did not realize the Application instance is not per user. That clears things up. I need the user to have the same data view on several other pages, so decided to subclasses WebSession and placed the db instance there. I suppose this to be a good central location for the individual user. Everything is working fine now - each user has their own db instance/view across the several pages of the application. I got the idea of placing the db instance in the Application class from the Wicket Examples (org.apache.wicket.examples.repeater.RepeaterApplication). Is this not a best practice for an enterprise application? -Original Message- From: McIlwee, Craig [mailto:craig.mcil...@openroadsconsulting.com] Sent: Wednesday, September 16, 2009 20:05 To: users@wicket.apache.org Subject: Re: same data set shows for all users You do realize that there is a single instance of the Application, not one per user, right? Your application holds an OrderDatabase and whenever a user enters a new date range they are altering the contents of the Map in that OrderDatabase. So user A sets a date range and fetch is called, updating the single OrderDatabase. User B logs in and his OrderDataProvider pulls items from the same OrderDatabase instance. You need to have an instance of this per user in the session instead of a single instance in the application. Or better would probably be to put it in the HomePage or somewhere else. Craig Open Roads Consulting, Inc. 757-546-3401 http://www.openroadsconsulting.com _ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Defaulting a DropDownChoice
Thanks for the response. How do I bind the playerModel to the DDC? If I did
the below extract the object out of the playerModel it would probably work.
Player player = (Player)playerModel.getObject();
final DropDownChoice downChoice = new DropDownChoice("name", new
Model(Player), playersModel, new ChoiceRenderer("username", "id"));
If I did this though, the player object would get serialized and I want to
avoid that. If I use:
final DropDownChoice downChoice = new DropDownChoice("name", new
CompoundPropertyModel(playerModel), playersModel, new
ChoiceRenderer("username", "id"));
This would work fine w/o serialization except that the compound expects a
setter with the name of the component from the object that comes from the
backing LDM (playerModel) so it would error. I essentially want it to not
use a setter, instead just store the value itself as the object.
Tim
Pedro Santos-6 wrote:
>
> The DDC uses the model choises internaly, if you want manage this model,
> use
> it on other places, why don't you keep an refecence to by yourself?
>
> setResponsePage(new ViewPicksPage(playersModel));
>
> on DDC default model will have only the selected item, provided by choices
> options you passed
>
> On Fri, Sep 18, 2009 at 10:45 AM, Tim Delesio wrote:
>
>> I'm trying to default a DDC (DropDownChoice) using the model I am passing
>> in. The page is getting passed in a LoadableDetachableModel which is of
>> Type Player. The list to back the DDC is a List.
>>
>> LoadableDetachableModel playersModel = new LoadableDetachableModel()
>>{
>>protected Object load()
>>{
>>return
>> playerManager.getPlayersInLeague(getActiveLeague());
>>}
>>};
>>
>> And here is the DDC.
>>
>> final DropDownChoice downChoice = new DropDownChoice("name", new
>> Model(),
>> playersModel, new ChoiceRenderer("username", "id"));
>>add(downChoice);
>>
>> downChoice.add(new AjaxFormComponentUpdatingBehavior("onChange")
>>{
>>
>>@Override
>>protected void onUpdate(AjaxRequestTarget target) {
>>setResponsePage(new ViewPicksPage(downChoice.getModel()));
>> }
>>
>>});
>>
>> The above code works but does not obviously does not default the DDC. I
>> want the default to be the playerModel that is being passed in to the
>> page.
>> If I pass the playerModel into the DDC (instead of the new Model()) I get
>> an
>> error saying that I can't set a model on a LDM (loadabledetachablemodel).
>> What is the correct way to default the DDC? I've read that I shouldn't
>> use
>> a LDM for backing as it is loadable, but then what model should I use?
>> Keep
>> in mind that I am trying to keep the memory footprint low and do not want
>> to
>> serialize objects unless I have to.
>>
>> Tim
>>
>
>
--
View this message in context:
http://www.nabble.com/Defaulting-a-DropDownChoice-tp25508933p25513112.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: Update Tree Model on Ajax timer. What's wrong ?
This wicket-tree seems really nice. Well done! Why isn't it in wicketstuff? It may even replace the "headache" swing wicket-extension one (in 1.5?)... Regards, Gabriel. svenmeier wrote: > > > > ... you should definitely take a look at > http://code.google.com/p/wicket-tree . > > > > -- View this message in context: http://www.nabble.com/Update-Tree-Model-on-Ajax-timer.-What%27s-wrong---tp25468038p25513102.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Is it a bug that Enclosure is not invoking component resolver to resolve its children?
you are welcome to provide a patch.
-igor
On Thu, Sep 17, 2009 at 1:57 PM, Chris Colman
wrote:
> As can be seen by the Enclosure.getChildComponent method below the
> component resolver expects to find the 'child' within its own parent -
> i.e. it assumes that its *child* is actually its sibling via:
>
> child = parent.get(childId.toString());
>
> While all other children of the common parent are resolved perfectly by
> the component resolver the fact that the enclosure's child is not really
> a child of the enclosure's parent (at least not in the markup) but
> rather a child of the enclosure itself seems to mean that the normal
> resolving mechanism that allowed all other 'siblings' to be instantiated
> by my custom component resolver is bypassed.
>
> Is that a bug? If it is a bug is there something I can do to work around
> this to make this 'child' get resolved like all the other children of
> the enclosure's parent? i.e. somehow cause my custom component resolver
> to be invoke like it is for the other children.
>
>
>> public Component< ? > getChildComponent()
>> {
>> if (childComponent == null)
>> {
>> MarkupContainer< ? > parent =
>> getEnclosureParent();
>>
>> if (childId == null)
>> {
>> throw new MarkupException(
>> "You most likely forgot to
>> register the EnclosureHandler with the MarkupParserFactory");
>> }
>>
>> final Component< ? > child =
>> parent.get(childId.toString());
>> if (child == null)
>> {
>> throw new MarkupException(
>> "Didn't find child component of
>> with id='" + childId +
>> "'. Component: " +
>> this.toString());
>> }
>> childComponent = child;
>> }
>> return childComponent;
>> }
>>
>> -
>> 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
Re: Bug with firefox when submitting an ajax form inside a modal window
svenmeier wrote: > > Short answer: > You have to enclose your modal window in a form component, see modal > window javadoc. > Hmm what exactly does that mean? I tried changing my modalWindow from: to and but neither of those work, the form fails on the first submit. What I get confused about is how it could work the first time in firefox, but then get rendered differently the second time. I tried to make my inner panel unaware that its inside a modal window, so it has no referenceto a ModalWindow (because on fallback i put the panel into a Page and redirect, and thought that the panel shouldn't need to know about its parent). But could a solution be to pass a modalwindow reference and close the panel after a form submit, and reopen it? Its not great usability though, so I'm hoping i'm just missing something. -- View this message in context: http://www.nabble.com/Bug-with-firefox-when-submitting-an-ajax-form-inside-a-modal-window-tp25501735p25512670.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: Bug with firefox when submitting an ajax form inside a modal window
Short answer:
You have to enclose your modal window in a form component, see modal
window javadoc.
Long answer:
The modal window javascript generates an additional form when opening.
When your panel is re-rendered, Firefox drops your form from the markup
because in HTML it's not allowed to have forms nested in other forms.
The required parental form component will force your form component to
be rendered as a DIV.
My questions:
-Could someone explain what this additional form is needed for?
-Are there plans to improve this situation in 1.4?
Sven
Anthony DePalma wrote:
To be more specific, I ran into this problem when trying to submit a form
from a panel that was rendered inside a modal window, but only if the panel
itself was rendered by ajax. In my case, that meant calling
somePanel.replaceWith(TestPanel), and having a form inside TestPanel fail.
The problem only happens with firefox. I created a TestPanel to demonstrate
the problem. To replicate, you can put this panel inside a modal window and
click submit twice.
import org.apache.wicket.Component;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.ajax.markup.html.form.AjaxButton;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.panel.Panel;
/**
* TestPanel.java
* If this panel is put inside a modal window, it should break firefox on
the second submit
*
*/
public class TestPanel extends Panel {
// constructor
public TestPanel(final String id) {
super(id);
setOutputMarkupId(true);
final Form form = new Form("f");
form.add(new AjaxButton("a") {
@Override
protected void onSubmit(AjaxRequestTarget target, Form form) {
Component c = form.getParent();
TestPanel t = new TestPanel(c.getId());
c.replaceWith(t);
target.addComponent(t);
}
});
add(form);
}
}
TestPanel.html:
Will the second submit error in FF
This is what is rendered:
FIRST RENDER:
Will the second submit error in FF
SECOND RENDER:
Will the second submit error in FF
For some reason the tag seems to drop. Also, I dont think this
happened in 1.3. I believe this is the same error someone was describing
here:
http://www.nabble.com/Wicketstuff-releases--td24931965i20.html#a24960539
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: rpc question
Hi Petr, sorry, I've misunderstood your mail... :) you've meant the other way round. May be you should try to build a restful webservice. It's also possible with wicket if you decide xml as a resultpage. For example: http://java.dzone.com/news/wicket-creating-restful-urls Am Fri, 18 Sep 2009 17:48:01 +0200 schrieb Marc Ende : > Hi Petr, > > I think you should use a LoadableDetachableModel. Within the method > load() you can execute your call to the webservice or other > remote-service. > > http://cwiki.apache.org/WICKET/working-with-wicket-models.html#WorkingwithWicketmodels-DetachableModels > > yours > marc > > Am Fri, 18 Sep 2009 14:20:27 + > schrieb Petr Kobalíček : > > > Hi list, > > > > is there a simple tutorial about making RPC services in wicket? I > > mean all integrated with wicket RequestCycle and Sessions, ideally > > that I can expose web services through some Wicket page like class. > > I'm porting one application and we have admin interface in qooxdoo > > toolkit (it communicates through json requests). > > > > I'd like to hear about "wicket" solution to this problem. > > > > Thanks for possibilities > > - Petr > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > signature.asc Description: PGP signature
Re: rpc question
ideally that I can expose web services through some Wicket page like class I remember this post with question: How to easily provide simple RESTful Web Services with Wicket? http://blog.brunoborges.com.br/2008/11/restful-web-services-with-wicket.html On Fri, Sep 18, 2009 at 11:20 AM, Petr Kobalíček wrote: > Hi list, > > is there a simple tutorial about making RPC services in wicket? I mean > all integrated with wicket RequestCycle and Sessions, ideally that I > can expose web services through some Wicket page like class. I'm > porting one application and we have admin interface in qooxdoo toolkit > (it communicates through json requests). > > I'd like to hear about "wicket" solution to this problem. > > Thanks for possibilities > - Petr > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: How to access text fields in a data view
What the example lacks is the Submit button processing for the entire form.
There are probably lots of ways to handle this - ajax and non-ajax.
Once you get the submit button you want to use defined, that is where you
can access all the items in the repeater by visiting the "children" of the
form
I did something like this within the onSubmit of whatever button/link you
choose:
form.visitFormComponents(new FormComponent.AbstractVisitor() {
@Override
protected void onFormComponent(FormComponent formComponent) {
if
(formComponent.getInputName().contains(":orderComponent:orderNo")) {
if (formComponent.getConvertedInput() != null) {
// update stuff
}
}
}
}
the getInputName() allows you to check which component name you are working
with. All of the components in the same repeater "row" will have the same
number. Run the example again and do a view page source. You will see what
I mean. simple:41:id, simple:41:firstname, etc. I have only used this in
one application so far and only needed one input field in the repeater. I
am sure there may be better ways to get at the entire row, then process each
component in that row. Perhaps each row could be a markup container then
process the children of that container?
This is just one way. I am sure those with more experience will show other
ways.
On Fri, Sep 18, 2009 at 10:06 AM, Randy wrote:
>
> In the Wicket Examples, there is a data view with editable values
> (org.apache.wicket.examples.repeater.FormPage). It is not clear to me how
> to access the updated text field(s) so that changes can be recorded in the
> actual data item instance for the row. I see how to reference the data
> item
> instance, but am not sure how to access the text fields.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: rpc question
Hi Petr, I think you should use a LoadableDetachableModel. Within the method load() you can execute your call to the webservice or other remote-service. http://cwiki.apache.org/WICKET/working-with-wicket-models.html#WorkingwithWicketmodels-DetachableModels yours marc Am Fri, 18 Sep 2009 14:20:27 + schrieb Petr Kobalíček : > Hi list, > > is there a simple tutorial about making RPC services in wicket? I mean > all integrated with wicket RequestCycle and Sessions, ideally that I > can expose web services through some Wicket page like class. I'm > porting one application and we have admin interface in qooxdoo toolkit > (it communicates through json requests). > > I'd like to hear about "wicket" solution to this problem. > > Thanks for possibilities > - Petr > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > signature.asc Description: PGP signature
Re: [OT] Moving to SVN...best practices for project layout?
If your product projects will have independent release cycles, you definitely should choose option B. Otherwise you will not be able to have separate bug fix branches etc... How would you like to resolve the according artifact of the common project? If you are using a maven repository as well, maven will do the job for you without any extra effort as soon as you deploy the according artifact to the maven repository... And with a little naming convention for Tags you can relate common project tags with specific product project tags... Regards, CAK Am 18.09.2009 um 17:05 schrieb Doug Leeper: We have been using CVS for a long time now and want to move to SVN. We have an empty SVN repository created but have questions on how we should set up our multiple projects that all utilize a common project in conjunction with tags, branches, releases. To keep things somewhat consistent between the CVS/SVN, we know we want to first separate between python and Java (our 2 development languages). I believe our first SVN decision would be to have two separate repositories for these technologies and have multiple projects in these repositories. FYI: Java and Python are completely separate code bases, are not dependent upon one another, and have a different release. Now within each of these repositories, we both have a common utility project and multiple product projects. When we release/tag a product, we would like to release/tag only the common and specific product (or does it matter?). We have done some research SVN but are looking for best practices based on our requirements. We were hoping that someone might be able to point us in the right direction/place of information on achieving a manageable/effective source repository and build management. I have reviewed Wicket's project hierarchy and seems relevant to ours. However, when wicket is built/released, all projects are tagged and built which is contrary to our goal. We use Maven and its project structure. Our common project is a referenced module in each product project. Which of the following options is recommended? Are there any good specific references that would help determine this? (we have googled but a lot of information is returned) I did find this link which was helpful: http://svnbook.red-bean.com/en/1.1/ch05s04.html which is why we are leaning towards Option B. Option A: /java + trunk + common + project 1 + project N + tags + common + project 1 + project N + branches + common + project 1 + project N + releases + common + project 1 + project N Option B: /java + common + trunk + tags + branches + releases + project 1 + trunk + tags + branches + releases + project N + trunk + tags + branches + releases Option C: (this option is a separate repo for each project) /java/common + trunk + tags + branches + releases /java/project1 + trunk + tags + branches + releases /java/project2 + trunk + tags + branches + releases Thanks in advance! - Doug -- Carsten Kaiser Principal Consultant mailto:carsten.kai...@valtech.de Mobile: +49 170 5270206 Valtech GmbH Werner-Heisenberg-Straße 2 63263 Neu-Isenburg Germany Phone: +49 6102 88468-0 Fax: +49 6102 88468-28 http://www.valtech.de Geschäftsführer: Ingo Kriescher Amtsgericht Düsseldorf HRB48672 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
[OT] Moving to SVN...best practices for project layout?
We have been using CVS for a long time now and want to move to SVN. We have an empty SVN repository created but have questions on how we should set up our multiple projects that all utilize a common project in conjunction with tags, branches, releases. To keep things somewhat consistent between the CVS/SVN, we know we want to first separate between python and Java (our 2 development languages). I believe our first SVN decision would be to have two separate repositories for these technologies and have multiple projects in these repositories. FYI: Java and Python are completely separate code bases, are not dependent upon one another, and have a different release. Now within each of these repositories, we both have a common utility project and multiple product projects. When we release/tag a product, we would like to release/tag only the common and specific product (or does it matter?). We have done some research SVN but are looking for best practices based on our requirements. We were hoping that someone might be able to point us in the right direction/place of information on achieving a manageable/effective source repository and build management. I have reviewed Wicket's project hierarchy and seems relevant to ours. However, when wicket is built/released, all projects are tagged and built which is contrary to our goal. We use Maven and its project structure. Our common project is a referenced module in each product project. Which of the following options is recommended? Are there any good specific references that would help determine this? (we have googled but a lot of information is returned) I did find this link which was helpful: http://svnbook.red-bean.com/en/1.1/ch05s04.html which is why we are leaning towards Option B. Option A: /java + trunk + common + project 1 + project N + tags + common + project 1 + project N + branches + common + project 1 + project N + releases + common + project 1 + project N Option B: /java + common + trunk + tags + branches + releases + project 1 + trunk + tags + branches + releases + project N + trunk + tags + branches + releases Option C: (this option is a separate repo for each project) /java/common + trunk + tags + branches + releases /java/project1 + trunk + tags + branches + releases /java/project2 + trunk + tags + branches + releases Thanks in advance! - Doug
rpc question
Hi list, is there a simple tutorial about making RPC services in wicket? I mean all integrated with wicket RequestCycle and Sessions, ideally that I can expose web services through some Wicket page like class. I'm porting one application and we have admin interface in qooxdoo toolkit (it communicates through json requests). I'd like to hear about "wicket" solution to this problem. Thanks for possibilities - Petr - 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
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'>
> >
> > > 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
>
>
>
> >>>
> >>>
> >>
> >>
> >
> >
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
How to access text fields in a data view
In the Wicket Examples, there is a data view with editable values (org.apache.wicket.examples.repeater.FormPage). It is not clear to me how to access the updated text field(s) so that changes can be recorded in the actual data item instance for the row. I see how to reference the data item instance, but am not sure how to access the text fields. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Defaulting a DropDownChoice
The DDC uses the model choises internaly, if you want manage this model, use
it on other places, why don't you keep an refecence to by yourself?
setResponsePage(new ViewPicksPage(playersModel));
on DDC default model will have only the selected item, provided by choices
options you passed
On Fri, Sep 18, 2009 at 10:45 AM, Tim Delesio wrote:
> I'm trying to default a DDC (DropDownChoice) using the model I am passing
> in. The page is getting passed in a LoadableDetachableModel which is of
> Type Player. The list to back the DDC is a List.
>
> LoadableDetachableModel playersModel = new LoadableDetachableModel()
>{
>protected Object load()
>{
>return playerManager.getPlayersInLeague(getActiveLeague());
>}
>};
>
> And here is the DDC.
>
> final DropDownChoice downChoice = new DropDownChoice("name", new Model(),
> playersModel, new ChoiceRenderer("username", "id"));
>add(downChoice);
>
> downChoice.add(new AjaxFormComponentUpdatingBehavior("onChange")
>{
>
>@Override
>protected void onUpdate(AjaxRequestTarget target) {
>setResponsePage(new ViewPicksPage(downChoice.getModel()));
> }
>
>});
>
> The above code works but does not obviously does not default the DDC. I
> want the default to be the playerModel that is being passed in to the page.
> If I pass the playerModel into the DDC (instead of the new Model()) I get
> an
> error saying that I can't set a model on a LDM (loadabledetachablemodel).
> What is the correct way to default the DDC? I've read that I shouldn't use
> a LDM for backing as it is loadable, but then what model should I use?
> Keep
> in mind that I am trying to keep the memory footprint low and do not want
> to
> serialize objects unless I have to.
>
> Tim
>
Defaulting a DropDownChoice
I'm trying to default a DDC (DropDownChoice) using the model I am passing
in. The page is getting passed in a LoadableDetachableModel which is of
Type Player. The list to back the DDC is a List.
LoadableDetachableModel playersModel = new LoadableDetachableModel()
{
protected Object load()
{
return playerManager.getPlayersInLeague(getActiveLeague());
}
};
And here is the DDC.
final DropDownChoice downChoice = new DropDownChoice("name", new Model(),
playersModel, new ChoiceRenderer("username", "id"));
add(downChoice);
downChoice.add(new AjaxFormComponentUpdatingBehavior("onChange")
{
@Override
protected void onUpdate(AjaxRequestTarget target) {
setResponsePage(new ViewPicksPage(downChoice.getModel()));
}
});
The above code works but does not obviously does not default the DDC. I
want the default to be the playerModel that is being passed in to the page.
If I pass the playerModel into the DDC (instead of the new Model()) I get an
error saying that I can't set a model on a LDM (loadabledetachablemodel).
What is the correct way to default the DDC? I've read that I shouldn't use
a LDM for backing as it is loadable, but then what model should I use? Keep
in mind that I am trying to keep the memory footprint low and do not want to
serialize objects unless I have to.
Tim
RE: same data set shows for all users
I did not realize the Application instance is not per user. That clears things up. I need the user to have the same data view on several other pages, so decided to subclasses WebSession and placed the db instance there. I suppose this to be a good central location for the individual user. Everything is working fine now - each user has their own db instance/view across the several pages of the application. I got the idea of placing the db instance in the Application class from the Wicket Examples (org.apache.wicket.examples.repeater.RepeaterApplication). Is this not a best practice for an enterprise application? -Original Message- From: McIlwee, Craig [mailto:craig.mcil...@openroadsconsulting.com] Sent: Wednesday, September 16, 2009 20:05 To: users@wicket.apache.org Subject: Re: same data set shows for all users You do realize that there is a single instance of the Application, not one per user, right? Your application holds an OrderDatabase and whenever a user enters a new date range they are altering the contents of the Map in that OrderDatabase. So user A sets a date range and fetch is called, updating the single OrderDatabase. User B logs in and his OrderDataProvider pulls items from the same OrderDatabase instance. You need to have an instance of this per user in the session instead of a single instance in the application. Or better would probably be to put it in the HomePage or somewhere else. Craig Open Roads Consulting, Inc. 757-546-3401 http://www.openroadsconsulting.com _ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Hibernate session (LazyInitializationException)
yes - it run's smoothly together ... Am 18.09.2009 um 07:44 schrieb Michael Mosmann: Am Freitag, den 18.09.2009, 00:35 +0200 schrieb Peter Ertl: as an further improvement use salve to completely remove your headache :-) http://code.google.com/p/salve thank you.. interesting stuff.. do you have any experience in combination with hibernate? mm:) Am 17.09.2009 um 23:51 schrieb Michael Mosmann: Hi, (Solution with no Spring is preferable). Use Spring, because it will limit your headache.. Maybe this is usefull: http://www.wicket-praxis.de/blog/download/ use Link behind "Praxisbuch Wicket Beispielcode" for a maven-based project with: - Spring (open session in view filter, @SpringBean-Annotation support, Hibernate UnitTest) - Hibernate (Hibernate Annotation Support) mm:) - 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 - 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
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: post a form to external website
El vie, 18-09-2009 a las 10:51 +, Vadim Tesis escribió: > all, > > > > i have a form with some input fields. after the user populates the form and > hits submit button, i'd like to do some processing on my website and then > redirect the user to external website by posting another form with > dynamically generated hidden fields. > > what's the best way to do it in wicket 1.4? There is no automatic Wicket way to do this. You could forward the data with UrlConnection or apache-httpclient in your onSubmit() callback method. > > > > Thanks, > > Vadim > > _ > Hotmail: Powerful Free email with security by Microsoft. > http://clk.atdmt.com/GBL/go/171222986/direct/01/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Is it the best way to code a Link depending on a condition
cmoulliard wrote:
What I have done to avoid to repeat the creation of the labels is to define
and use static method
private Label labelTitle;
public static Label getLabelTitle(String title) {
return new Label("title",new Model( title ));
}
I personally would name this method createLabelTitle(String title) or
getNewLabelTitle(String title), for explicitness.
Furthermore, I would directly provide it with a "final IModel
title" attribute, not to dictate how the data has to be provided
(dynamic or not for example).
In the end, this method is fine for just a label, but for anything more
complex a panel would be the way to go I would say. The main exception
here I see right now is the case of pages.
For example, if we're speaking of a page title, then I would define it
in my base page and make an abstract String getTitle() method in the
base page so I'm sure everyone set it up later on. I would do the same
if it's a specific kind of structured page, for example an abstract
class ContentHoldingPage extend TheBasePage.
++
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxLazyLoadPanel
i'm using the Wicket Wizard and the list is generated out of previous
input, so i have to use the AjaxLazyLoadPanel
you can use dynamic models
http://cwiki.apache.org/WICKET/working-with-wicket-models.html#WorkingwithWicketmodels-DynamicModels
is it in principle possible to load this dynamic list with ajax lazy load?
or are there any problems with my code?
yes is possible
take a look at http://wicket.apache.org/examplefragments.html
you are using
to markup the component made with Fragment, use div or span...
On Fri, Sep 18, 2009 at 7:50 AM, Christoph Hochreiner <
ch.hochrei...@gmail.com> wrote:
> Hi
>
> i've experienced some problems with the AjaxLazyLoadPanel:
>
> the task is, to load a dynamic list (1- n) of String | Checkbox
> like this:
>
> String | Checkbox
> String | Checkbox
> String | Checkbox
>
>
> this works with excellent with the Listview:
>
> i'm using the Wicket Wizard and the list is generated out of previous
> input, so i have to use the AjaxLazyLoadPanel
>
>
> i've tried to perform this task with a Fragment
>
>
> KeyListAjaxPanel is a wrapper like "NameWrapper" in
> http://cwiki.apache.org/WICKET/listview-with-checkboxes.html
>
>
>
> is it in principle possible to load this dynamic list with ajax lazy load?
> or are there any problems with my code?
>
> Christoph
> ==
>
> Code:
>
>
>
> ---Panel
> of wizard
>add(new AjaxLazyLoadPanel("wrapper", new Model()) {
>
>@Override
>public Component getLazyLoadComponent(final String id) {
>
>class KeyListAjaxPanel extends Fragment{
>
>private List formKeys = new ArrayList();
>
>
>public KeyListAjaxPanel(final String id, final
> String markupId) {
>super(id, markupId);
>formKeys.add(new KeyCheckBoxWrapper("dynamic item
> 1"));
>formKeys.add(new KeyCheckBoxWrapper("dynamic item
> 2"));
>formKeys.add(new KeyCheckBoxWrapper("dynamic item
> 3"));
>formKeys.add(new KeyCheckBoxWrapper("dynamic item
> 4"));
>
>ListView listView = new ListView("list",
> formKeys)
>{
>@Override
>protected void populateItem(ListItem
> item)
>{
>KeyCheckBoxWrapper wrapper =
> (KeyCheckBoxWrapper)item.getModelObject();
>item.add(new Label("name",
> wrapper.getName()));
>item.add(new
> CheckBox("check", new
> PropertyModel(wrapper, "selected")));
>}
>};
>
>listView.setReuseItems(true);
>
>add(listView);
>
>}
>
>}
>
>return new KeyListAjaxPanel("wrapper", "fragmentid");
>
>}
>
>});
>
> ---Panel
> of wizard
>
>
> ---HTML
> for Panel of wizard
>
>
>
>
>
>
>
>
>
>
>
>text
>
>
>
>
>
>
> ---HTML
> for Panel of wizard
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
post a form to external website
all, i have a form with some input fields. after the user populates the form and hits submit button, i'd like to do some processing on my website and then redirect the user to external website by posting another form with dynamically generated hidden fields. what's the best way to do it in wicket 1.4? Thanks, Vadim _ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/171222986/direct/01/
AjaxLazyLoadPanel
Hi
i've experienced some problems with the AjaxLazyLoadPanel:
the task is, to load a dynamic list (1- n) of String | Checkbox
like this:
String | Checkbox
String | Checkbox
String | Checkbox
this works with excellent with the Listview:
i'm using the Wicket Wizard and the list is generated out of previous
input, so i have to use the AjaxLazyLoadPanel
i've tried to perform this task with a Fragment
KeyListAjaxPanel is a wrapper like "NameWrapper" in
http://cwiki.apache.org/WICKET/listview-with-checkboxes.html
is it in principle possible to load this dynamic list with ajax lazy load?
or are there any problems with my code?
Christoph
==
Code:
---Panel
of wizard
add(new AjaxLazyLoadPanel("wrapper", new Model()) {
@Override
public Component getLazyLoadComponent(final String id) {
class KeyListAjaxPanel extends Fragment{
private List formKeys = new ArrayList();
public KeyListAjaxPanel(final String id, final String
markupId) {
super(id, markupId);
formKeys.add(new KeyCheckBoxWrapper("dynamic item 1"));
formKeys.add(new KeyCheckBoxWrapper("dynamic item 2"));
formKeys.add(new KeyCheckBoxWrapper("dynamic item 3"));
formKeys.add(new KeyCheckBoxWrapper("dynamic item 4"));
ListView listView = new ListView("list",
formKeys)
{
@Override
protected void populateItem(ListItem
item)
{
KeyCheckBoxWrapper wrapper =
(KeyCheckBoxWrapper)item.getModelObject();
item.add(new Label("name",
wrapper.getName()));
item.add(new CheckBox("check",
new
PropertyModel(wrapper, "selected")));
}
};
listView.setReuseItems(true);
add(listView);
}
}
return new KeyListAjaxPanel("wrapper", "fragmentid");
}
});
---Panel
of wizard
---HTML
for Panel of wizard
text
---HTML
for Panel of wizard
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Is it the best way to code a Link depending on a condition
What I have done to avoid to repeat the creation of the labels is to define
and use static method
private Label labelTitle;
public static Label getLabelTitle(String title) {
return new Label("title",new Model( title ));
}
Joseph Pachod wrote:
>
> cmoulliard wrote:
>> (...)
>> I think that this is a general remark that some users make about Wicket.
>> It
>> is very difficult to reuse part of the code.
>>
>> Here is another example :
>>
>> I have a label called id which is used in different page. The way
>> proposes
>> by Wicket to code it is
>>
>> Page Request
>>
>> item.add(new Label("id", String.valueOf(request.getId(;
>>
>> Page Notification
>>
>> item.add(new Label("id", String.valueOf(notification.getId(;
>>
>> When we compare page request and page notification, we see that we repeat
>> the same code two times.
> Hi
>
> I think the "wicket way" here may be to create a panel containing this
> label and then reuse the panel. The panel could also have a model in
> order to get the label content.
>
> Would this solve your repetition issue ?
>
> ++
> joseph
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
-
Charles Moulliard
SOA Architect
My Blog : http://cmoulliard.blogspot.com/ http://cmoulliard.blogspot.com/
--
View this message in context:
http://www.nabble.com/Is-it-the-best-way-to-code-a-Link-depending-on-a-condition-tp25488603p25504977.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Is it the best way to code a Link depending on a condition
cmoulliard wrote:
(...)
I think that this is a general remark that some users make about Wicket. It
is very difficult to reuse part of the code.
Here is another example :
I have a label called id which is used in different page. The way proposes
by Wicket to code it is
Page Request
item.add(new Label("id", String.valueOf(request.getId(;
Page Notification
item.add(new Label("id", String.valueOf(notification.getId(;
When we compare page request and page notification, we see that we repeat
the same code two times.
Hi
I think the "wicket way" here may be to create a panel containing this
label and then reuse the panel. The panel could also have a model in
order to get the label content.
Would this solve your repetition issue ?
++
joseph
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
