Re: Close modal dialog backdrop after ajax form submission.
And you'll need hide-modal.js:
define(["jquery", "bootstrap/modal"], function($) {
// Hides a modal.
return function(modalId) {
var $modal = $('#' + modalId);
if ($modal.length > 0) {
$modal.modal('hide');
}
else {
// The modal's already gone, but the backdrop may still
be there.
$('body').removeClass('modal-open');
$('.modal-backdrop').remove();
}
}
});
On 09/04/2014, at 10:00 AM, Geoff Callender wrote:
> Is it wise to have the client-side close the modal before the server-side has
> handled the submit? What if there's an error?
>
> If you're happy to wait until onSuccess() server-side, then here's how I do
> it...
>
> Move your afterRender() stuff into ModalContainer and add a hide() method...
>
> public class ModalContainer implements ClientElement {
>
> // Parameters
>
> @Parameter(name = "componentClientId", value =
> "prop:componentResources.id", defaultPrefix = BindingConstants.LITERAL)
> private String componentClientId;
>
> // Generally useful bits and pieces
>
> @Inject
> private JavaScriptSupport javaScriptSupport;
>
> @Inject
> private AjaxResponseRenderer ajaxResponseRenderer;
>
> // The code
>
> @Override
> public String getClientId() {
> return componentClientId;
> }
>
> void afterRender() {
>
> javaScriptSupport.require("activate-modal").with(componentClientId, new
> JSONObject());
> }
>
> public void hide() {
> ajaxResponseRenderer.addCallback(makeScriptToHideModal());
> }
>
> private JavaScriptCallback makeScriptToHideModal() {
> return new JavaScriptCallback() {
> public void run(JavaScriptSupport javascriptSupport) {
>
> javascriptSupport.require("hide-modal").with(componentClientId);
> }
> };
> }
>
> }
>
> ...then change the third line of your tml to this...
>
>
>
> ...and in the associated java do something like this...
>
> @InjectComponent
> private ModalContainer dailyCommentModal;
>
> void onSuccessFromTheBodyIGaveToModalContainer() {
>
> dailyCommentModal.hide();
>
> // etc.
> }
>
> Geoff
>
> On 09/04/2014, at 2:04 AM, George Christman wrote:
>
>> Hi guys, I'm using the bootstrap modal component and I have a tapestry ajax
>> form nested within it. When I submit the form I'm looking to close out the
>> modal dialog box assuming no clientside validation errors ocure long with
>> the backdrop. I have it working with the exception of closing out the
>> backdrop. Does anybody know how to achieve this?
>>
>> The code.
>>
>>
>>
>>
>>
>>
>>
>>x
>>${dailyCommentTitle}
>> Daily Comment
>>
>>
>>> value="dailyCommentText" validate="required"/>
>>
>>
>>> data-dismiss="modal">Close
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ModalContainer.tml
>>
>> http://tapestry.apache.org/schema/tapestry_5_3.xsd";
>> xmlns:p="tapestry:parameter">
>>
>>
>>
>>
>>
>>
>> @Parameter(required = true, defaultPrefix = BindingConstants.LITERAL)
>>@Property
>>private String clientId;
>>
>>public void afterRender() {
>>JSONObject json = new JSONObject("id", clientId);
>>javaScriptSupport.require("warning-modal").with(json);
>>}
>>
>>
>> define(["jquery", "bootstrap/modal"], function($) {
>>
>>runDialog = function(spec) {
>>
>>$("#" + spec.id).modal();
>>
>>};
>>return runDialog;
>> });
>> --
>> George Christman
>> www.CarDaddy.com
>> P.O. Box 735
>> Johnstown, New York
>
Re: Close modal dialog backdrop after ajax form submission.
Please disregard the answer below. Fat finger syndrome at work...
On 09/04/2014, at 9:32 AM, Geoff Callender wrote:
> Are you asking how to do this client-side without waiting for a server-side
> response?
>
> If not, then you can do this...
>
> Add this to ModalContainer.java:
>
> public void hide() {
>
> ajaxResponseRenderer.addCallback(makeScriptToHideModal());
>
> }
>
>
>
> private JavaScriptCallback makeScriptToHideModal() {
>
> return new JavaScriptCallback() {
>
> public void run(JavaScriptSupport javascriptSupport) {
>
> javascriptSupport.require("hide-modal").with(componentClientId);
>
> }
>
> };
>
> }
>
>
> in the same class as your afterRender():
>
> void onSuccessFromTheComponentInTheBody() {
>
> crtClientContractModal.hide();
>
>
>
> // ClientContract clientContract =
>
> // clientFinder.findClientContractShallowish(clientContractId);
>
> clientId = clientContract.getClient().getId();
>
>
>
> populateBody();
>
> renderZones(paneZone);
>
> }
>
>
> On Wednesday, 9 April 2014, George Christman wrote:
> Thanks Lance, attempting to figure it out now.
>
>
> On Tue, Apr 8, 2014 at 12:32 PM, Lance Java wrote:
>
> > I assume you could hook on to one of the clientside events published during
> > submit / validate
> >
> > http://tapestry.apache.org/5.4/coffeescript/events.html
> >
>
>
>
> --
> George Christman
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
Re: Close modal dialog backdrop after ajax form submission.
Is it wise to have the client-side close the modal before the server-side has
handled the submit? What if there's an error?
If you're happy to wait until onSuccess() server-side, then here's how I do
it...
Move your afterRender() stuff into ModalContainer and add a hide() method...
public class ModalContainer implements ClientElement {
// Parameters
@Parameter(name = "componentClientId", value =
"prop:componentResources.id", defaultPrefix = BindingConstants.LITERAL)
private String componentClientId;
// Generally useful bits and pieces
@Inject
private JavaScriptSupport javaScriptSupport;
@Inject
private AjaxResponseRenderer ajaxResponseRenderer;
// The code
@Override
public String getClientId() {
return componentClientId;
}
void afterRender() {
javaScriptSupport.require("activate-modal").with(componentClientId, new
JSONObject());
}
public void hide() {
ajaxResponseRenderer.addCallback(makeScriptToHideModal());
}
private JavaScriptCallback makeScriptToHideModal() {
return new JavaScriptCallback() {
public void run(JavaScriptSupport javascriptSupport) {
javascriptSupport.require("hide-modal").with(componentClientId);
}
};
}
}
...then change the third line of your tml to this...
...and in the associated java do something like this...
@InjectComponent
private ModalContainer dailyCommentModal;
void onSuccessFromTheBodyIGaveToModalContainer() {
dailyCommentModal.hide();
// etc.
}
Geoff
On 09/04/2014, at 2:04 AM, George Christman wrote:
> Hi guys, I'm using the bootstrap modal component and I have a tapestry ajax
> form nested within it. When I submit the form I'm looking to close out the
> modal dialog box assuming no clientside validation errors ocure long with
> the backdrop. I have it working with the exception of closing out the
> backdrop. Does anybody know how to achieve this?
>
> The code.
>
>
>
>
>
>
>
>x
>${dailyCommentTitle}
> Daily Comment
>
>
> value="dailyCommentText" validate="required"/>
>
>
> data-dismiss="modal">Close
>
>
>
>
>
>
>
>
>
> ModalContainer.tml
>
> http://tapestry.apache.org/schema/tapestry_5_3.xsd";
> xmlns:p="tapestry:parameter">
>
>
>
>
>
>
> @Parameter(required = true, defaultPrefix = BindingConstants.LITERAL)
>@Property
>private String clientId;
>
>public void afterRender() {
>JSONObject json = new JSONObject("id", clientId);
>javaScriptSupport.require("warning-modal").with(json);
>}
>
>
> define(["jquery", "bootstrap/modal"], function($) {
>
>runDialog = function(spec) {
>
>$("#" + spec.id).modal();
>
>};
>return runDialog;
> });
> --
> George Christman
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
Re: Close modal dialog backdrop after ajax form submission.
Thanks Lance, attempting to figure it out now. On Tue, Apr 8, 2014 at 12:32 PM, Lance Java wrote: > I assume you could hook on to one of the clientside events published during > submit / validate > > http://tapestry.apache.org/5.4/coffeescript/events.html > -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: Close modal dialog backdrop after ajax form submission.
I assume you could hook on to one of the clientside events published during submit / validate http://tapestry.apache.org/5.4/coffeescript/events.html
Close modal dialog backdrop after ajax form submission.
Hi guys, I'm using the bootstrap modal component and I have a tapestry ajax
form nested within it. When I submit the form I'm looking to close out the
modal dialog box assuming no clientside validation errors ocure long with
the backdrop. I have it working with the exception of closing out the
backdrop. Does anybody know how to achieve this?
The code.
x
${dailyCommentTitle}
Daily Comment
Close
ModalContainer.tml
http://tapestry.apache.org/schema/tapestry_5_3.xsd";
xmlns:p="tapestry:parameter">
@Parameter(required = true, defaultPrefix = BindingConstants.LITERAL)
@Property
private String clientId;
public void afterRender() {
JSONObject json = new JSONObject("id", clientId);
javaScriptSupport.require("warning-modal").with(json);
}
define(["jquery", "bootstrap/modal"], function($) {
runDialog = function(spec) {
$("#" + spec.id).modal();
};
return runDialog;
});
--
George Christman
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
Re: NullPointer for service constructor
It seems like tapestry ioc has @PostInjection ( https://tapestry.apache.org/injection-in-detail.html#InjectioninDetail-Post-InjectionMethods) to receive a callback after the instance is configured.Somewhat similar to the afterPropertiesSet(). On Tue, Apr 8, 2014 at 3:55 PM, Lance Java wrote: > FYI, in spring ioc you work around this issue via implementing > InitializingBean.afterPropertiesSet() > > > http://docs.spring.io/spring/docs/2.5.6/api/org/springframework/beans/factory/InitializingBean.html > > As has been mentioned many times here, constructor injection is superior to > field injection for many reasons >
Re: NullPointer for service constructor
FYI, in spring ioc you work around this issue via implementing InitializingBean.afterPropertiesSet() http://docs.spring.io/spring/docs/2.5.6/api/org/springframework/beans/factory/InitializingBean.html As has been mentioned many times here, constructor injection is superior to field injection for many reasons
Re: NullPointer for service constructor
On Tue, 08 Apr 2014 10:04:20 -0300, Chris Mylonas wrote: Hi t5 aficionados, Hi! Am I correct in following this thread...that it is best to think of @inject as "lazy" inject? (After constructor) No. It's not lazy because the injection is done before the service instance. If so, without knowledge of tapestry internally, sounds like a familiar gotcha like onActivate/setupRender and instantiation/fetching-stuff I'm sorry, but the analogy is completely off. That plastic morphing sounds like a can of worms btw Actually, no, this isn't related to Plastic at all. That NPE would happen in the exact same way in Spring. Again, service classes are *not* transformed by Plastic at all. Instead, it creates proxies that delegate method calls to the service instances. Just Tapestry pages, components, mixins and classes in the base package are transformed. Chasing-those-exceptions is never fun, although I'd prefer to do that than compliance documentation and openssl heartbleed shenanigans! Cant believe it'll be Wednesday soon! Whoosh! :D -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: NullPointer for service constructor
Hi t5 aficionados, Am I correct in following this thread...that it is best to think of @inject as "lazy" inject? (After constructor) If so, without knowledge of tapestry internally, sounds like a familiar gotcha like onActivate/setupRender and instantiation/fetching-stuff That plastic morphing sounds like a can of worms btw Chasing-those-exceptions is never fun, although I'd prefer to do that than compliance documentation and openssl heartbleed shenanigans! Cant believe it'll be Wednesday soon! Cheers Chris On 08/04/2014 9:07 pm, "Thiago H de Paula Figueiredo" wrote: > On Tue, 08 Apr 2014 05:23:13 -0300, Lance Java > wrote: > > I'm sure Tapestry could do some byte code magic via plastic such that any >> @Inject fields accessed in the constructor were swapped out for getters >> with nice error messages. Sounds very messy / intrusive to me and I don't >> think it should be implemented. >> > > Hi, Lance! > > Hmmm, you're right, that's probably very doable (I'm not sure Plastic > already handles throwing exceptions, and it supports just the bytecode it > needs). You've thought in an angle I haven't though. :) Regarding being > implemented or not, I think this kind of NPE is one that occurs in the > exact same way with ordinary, non-Tapestry-IoC Java, so I agree that I > shouldn't be implemented and that constructor injection is the recommended > one. > > > On 7 Apr 2014 13:54, "Thiago H de Paula Figueiredo" >> wrote: >> >> On Sun, 06 Apr 2014 16:26:47 -0300, John wrote: >>> >>> problem solved, the Logger was of course not yet injected! Duh. I wish >>> the IoC stack dump were more helpful. >>> I'm not sure how (a better error message) that could be done. How could >>> Tapestry-IoC differentiate an exception caused by field injection not >>> done >>> yet from other exceptions? Even if it's just about NPEs, I cannot see how >>> that could be done. >>> >>> -- >>> Thiago H. de Paula Figueiredo >>> Tapestry, Java and Hibernate consultant and developer >>> http://machina.com.br >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >>> > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: NullPointer for service constructor
On Tue, 08 Apr 2014 05:23:13 -0300, Lance Java wrote: I'm sure Tapestry could do some byte code magic via plastic such that any @Inject fields accessed in the constructor were swapped out for getters with nice error messages. Sounds very messy / intrusive to me and I don't think it should be implemented. Hi, Lance! Hmmm, you're right, that's probably very doable (I'm not sure Plastic already handles throwing exceptions, and it supports just the bytecode it needs). You've thought in an angle I haven't though. :) Regarding being implemented or not, I think this kind of NPE is one that occurs in the exact same way with ordinary, non-Tapestry-IoC Java, so I agree that I shouldn't be implemented and that constructor injection is the recommended one. On 7 Apr 2014 13:54, "Thiago H de Paula Figueiredo" wrote: On Sun, 06 Apr 2014 16:26:47 -0300, John wrote: problem solved, the Logger was of course not yet injected! Duh. I wish the IoC stack dump were more helpful. I'm not sure how (a better error message) that could be done. How could Tapestry-IoC differentiate an exception caused by field injection not done yet from other exceptions? Even if it's just about NPEs, I cannot see how that could be done. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: NullPointer for service constructor
I'm sure Tapestry could do some byte code magic via plastic such that any @Inject fields accessed in the constructor were swapped out for getters with nice error messages. Sounds very messy / intrusive to me and I don't think it should be implemented. On 7 Apr 2014 13:54, "Thiago H de Paula Figueiredo" wrote: > On Sun, 06 Apr 2014 16:26:47 -0300, John wrote: > > problem solved, the Logger was of course not yet injected! Duh. I wish >> the IoC stack dump were more helpful. >> > > I'm not sure how (a better error message) that could be done. How could > Tapestry-IoC differentiate an exception caused by field injection not done > yet from other exceptions? Even if it's just about NPEs, I cannot see how > that could be done. > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
