How to get random-ish AJAX-created client IDs?
I guess I now have an infamous situation, a component inside a zone, which has a mixin. The mixin gets the client ID of it's component, which works great, until the zone gets updated. The zone now has random-ish client ID for the component. How do I fix my mixin so it gets the new client ID? Thanks - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Zone updates on IE?
I guess the problem didn't go away. I even saw it on Firefox once. I now know a little more about this. It seems to be an initialization race condition with some other vendor JS that's running onLoad() What happens is that Tapestry linkZone initialization code gets run before DOM (and the zone element) gets loaded and I get an error about the missing zone from the Tapestry.js. Does anyone have any idea on how to work around this? I can't get it to reproduce in development mode, but it happens on _some_ machines frequently and some none at all. On IE8. In production mode. Thanks! On Oct 24, 2011, at 4:15 PM, Lenny Primak wrote: It turns out IE is more sensitive to JS initialization order, especially in production mode. The cure was to put some objects into a LATE initialization stage, i.e javaScriptSupport.addInitializerCall(InitializationPriority.LATE, disableAfterSubmit, spec); On Oct 23, 2011, at 7:48 AM, Lenny Primak wrote: I decided to test my app on IE today and it isn't 100%. Most problems deal with AJAX/zone updates. This is especially true in production mode with scripts combined/minimized/compressed. I get all sorts of random problems with ZoneManager being not found etc. I am using IE8 on XP with tap5.3-beta-26 Thanks. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: How to get random-ish AJAX-created client IDs?
Could you use ... ?
@InjectContainer
private ClientElement container;
void afterRender() {
container.getClientId();
}
Steve.
On 25 October 2011 16:53, Lenny Primak lpri...@hope.nyc.ny.us wrote:
I guess I now have an infamous situation,
a component inside a zone, which has a mixin.
The mixin gets the client ID of it's component, which works great, until the
zone gets updated.
The zone now has random-ish client ID for the component. How do I fix my
mixin so it gets the new client ID?
Thanks
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: How to get random-ish AJAX-created client IDs?
I don't think those are called on Ajax updates. I use @SetupRender now and it
only works before the ajax update.
On Oct 25, 2011, at 5:00 AM, Steve Eynon steve.ey...@alienfactory.co.uk wrote:
Could you use ... ?
@InjectContainer
private ClientElement container;
void afterRender() {
container.getClientId();
}
Steve.
On 25 October 2011 16:53, Lenny Primak lpri...@hope.nyc.ny.us wrote:
I guess I now have an infamous situation,
a component inside a zone, which has a mixin.
The mixin gets the client ID of it's component, which works great, until the
zone gets updated.
The zone now has random-ish client ID for the component. How do I fix my
mixin so it gets the new client ID?
Thanks
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: How to get random-ish AJAX-created client IDs?
Hi,
On Tue, Oct 25, 2011 at 11:10 AM, Lenny Primak lpri...@hope.nyc.ny.uswrote:
I don't think those are called on Ajax updates.
SetupRender and the rest of the render phase events are called if the
component is inside the block that updates the zone (if it's the zones body,
than inside the zone). They aren't called on the page containing the zone.
I use @SetupRender now and it only works before the ajax update.
On Oct 25, 2011, at 5:00 AM, Steve Eynon steve.ey...@alienfactory.co.uk
wrote:
Could you use ... ?
@InjectContainer
private ClientElement container;
void afterRender() {
container.getClientId();
}
Steve.
On 25 October 2011 16:53, Lenny Primak lpri...@hope.nyc.ny.us wrote:
I guess I now have an infamous situation,
a component inside a zone, which has a mixin.
The mixin gets the client ID of it's component, which works great, until
the zone gets updated.
The zone now has random-ish client ID for the component. How do I fix
my mixin so it gets the new client ID?
Thanks
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: How to get random-ish AJAX-created client IDs?
My way of thinking about it is...
...if the whole component is rendered then the render phases are
called, but it a component is partially rendered, then they're not.
But you can always use t:trigger / to fire your own render events,
as mentioned here:
http://tapestry.1045711.n5.nabble.com/T5-2-Looking-For-A-RenderNotification-Mixin-Example-td4917771.html#a4920626
Steve.
On 25 October 2011 17:22, Dragan Sahpaski dragan.sahpa...@gmail.com wrote:
Hi,
On Tue, Oct 25, 2011 at 11:10 AM, Lenny Primak lpri...@hope.nyc.ny.uswrote:
I don't think those are called on Ajax updates.
SetupRender and the rest of the render phase events are called if the
component is inside the block that updates the zone (if it's the zones body,
than inside the zone). They aren't called on the page containing the zone.
I use @SetupRender now and it only works before the ajax update.
On Oct 25, 2011, at 5:00 AM, Steve Eynon steve.ey...@alienfactory.co.uk
wrote:
Could you use ... ?
@InjectContainer
private ClientElement container;
void afterRender() {
container.getClientId();
}
Steve.
On 25 October 2011 16:53, Lenny Primak lpri...@hope.nyc.ny.us wrote:
I guess I now have an infamous situation,
a component inside a zone, which has a mixin.
The mixin gets the client ID of it's component, which works great, until
the zone gets updated.
The zone now has random-ish client ID for the component. How do I fix
my mixin so it gets the new client ID?
Thanks
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: How to get random-ish AJAX-created client IDs?
Hmmm. I wonder why then the mixin stops working after zone update...
On Oct 25, 2011, at 5:22 AM, Dragan Sahpaski dragan.sahpa...@gmail.com wrote:
Hi,
On Tue, Oct 25, 2011 at 11:10 AM, Lenny Primak lpri...@hope.nyc.ny.uswrote:
I don't think those are called on Ajax updates.
SetupRender and the rest of the render phase events are called if the
component is inside the block that updates the zone (if it's the zones body,
than inside the zone). They aren't called on the page containing the zone.
I use @SetupRender now and it only works before the ajax update.
On Oct 25, 2011, at 5:00 AM, Steve Eynon steve.ey...@alienfactory.co.uk
wrote:
Could you use ... ?
@InjectContainer
private ClientElement container;
void afterRender() {
container.getClientId();
}
Steve.
On 25 October 2011 16:53, Lenny Primak lpri...@hope.nyc.ny.us wrote:
I guess I now have an infamous situation,
a component inside a zone, which has a mixin.
The mixin gets the client ID of it's component, which works great, until
the zone gets updated.
The zone now has random-ish client ID for the component. How do I fix
my mixin so it gets the new client ID?
Thanks
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: How to get random-ish AJAX-created client IDs?
Are you using JSONLiteral in your mixin? If your mixin does some javascript and stops working with no errors after a zone refresh I would suspect the JSON returned on the zone update is invalid. When this happens the JSON parser traps the error so you don't see any problems but nothing works after that. The changing client IDs can also be a problem. I wrote a selector binding for the tapestry5-jquery library that helps with that issue. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: How to get random-ish AJAX-created client IDs?
Thanks for the replies guys. Nope, not a JSON problem... The client IDs are correct, as the debugger tells me, but for some reason the event handler for the form submit button isn't getting called after a zone refresh. I guess this question is invalid, something else is going on. On Oct 25, 2011, at 6:29 AM, Barry Books wrote: Are you using JSONLiteral in your mixin? If your mixin does some javascript and stops working with no errors after a zone refresh I would suspect the JSON returned on the zone update is invalid. When this happens the JSON parser traps the error so you don't see any problems but nothing works after that. The changing client IDs can also be a problem. I wrote a selector binding for the tapestry5-jquery library that helps with that issue. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Mixins stop working after a zone update (please help)
Turns out that all my mixins aren't working after a zone update.
I am sure it's my fault somewhere, but I just can't figure out where.
Basically, if you put this mixin into a form that's inside the zone,
when the zone is refreshed, the mixin stops working.
It's not just this one, I have similar mixins that all stop working too just
like this.
Full code is available at http://code.google.com/p/flowlogix
Thank you!
-- Java Mixin
@Import(library=DisableAfterSubmit.js)
public class DisableAfterSubmit
{
@AfterRender
void addDisabler()
{
JSONObject spec = new JSONObject();
spec.put(elementId, submitButton.getClientId());
spec.put(formId, fs.getClientId());
js.addInitializerCall(disableAfterSubmit, spec);
}
@Environmental private JavaScriptSupport js;
@InjectContainer private ClientElement submitButton;
@Environmental private FormSupport fs;
}
JavaScript
/**
* Disable Submit button after AJAX Form Submission
*/
var DisableAfterSubmit = Class.create();
DisableAfterSubmit.prototype = {
initialize: function(elementId, formId) {
this.formId = formId;
this.elementId = elementId;
this.handler = this.doEnable.bindAsEventListener(this);
Event.observe($(elementId), 'click',
this.doDisable.bindAsEventListener(this));
},
doDisable: function() {
$(this.elementId).disable();
if($(this.formId).getStorage().zoneId != null) {
this.zoneId = Tapestry.findZoneManager(this.formId).element;
Event.observe($(this.zoneId), Tapestry.ZONE_UPDATED_EVENT,
this.handler);
$(this.formId).onsubmit();
}
else {
$(this.formId).submit();
}
},
doEnable: function() {
$(this.zoneId).stopObserving(Tapestry.ZONE_UPDATED_EVENT, this.handler);
var element = $(this.elementId);
if(element != null) {
$(this.elementId).enable();
}
}
};
// Extend the Tapestry.Initializer with a static method that instantiates us
Tapestry.Initializer.disableAfterSubmit = function(spec) {
new DisableAfterSubmit(spec.elementId, spec.formId);
};
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ActivationRequestParameter only works in a page?
The great thing about Tapestry, Don't like it change it! https://github.com/trsvax/tapestry-bootstrap/blob/master/src/main/java/com/trsvax/bootstrap/services/ComponentRequestParameterWorker.java - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ActivationRequestParameter only works in a page?
On Tue, 25 Oct 2011 10:28:54 -0200, Barry Books trs...@gmail.com wrote: The great thing about Tapestry, Don't like it change it! https://github.com/trsvax/tapestry-bootstrap/blob/master/src/main/java/com/trsvax/bootstrap/services/ComponentRequestParameterWorker.java Where 'change' means 'override Tapestry code without touching Tapestry sources'. ;) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Multizone updating and hibernate session loss
Hi, everybody. First of all, as a new forum user, I'd like to thank you all for the great job you're doing here. That said, here we go... I'm having trouble with an issue in a tapestry-hibernate app, and I'm not sure who to blame for it (tapestry, hibernate, or me). The scenario is as follows: I'm using a form to edit data from a User entity having these three particular attributes: Role is an enum, while Organization and Project are both entities. There are three roles: superadmin, admin and user. A superadmin belongs to no organization, so its organization attribute is set to null. Only users (i.e. neither superadmins nor admins) have projects assigned to them. role and organization are chosen through select objects, and projects are selected in a checklist component. When I select a role item, both organization and projects zones are updated, while selecting an organization triggers a projects' zone update only. The projects zone must be displayed only when the role is user. EditUser.tml: EditUser.java (solution 1): Now suppose I want to change a user's role from admin to superadmin. Organization and projects zones get correctly updated (with organization being set to null), but when I hit the submit button, I can see the user object has been reloaded (the debugger shows its memory id has changed), and while role holds the new value, organization is reverted back to its pre-null value, thus incorrect data being persisted. I kind of solved this by eliminating the @PageActivationContext annotation and using an onActivate() method to keep the session-persisted user object: EditUser.java (solution 2): But in this case, I get a new error. A bit of information, first. The Organization entity has itself a projects attribute too: I need to read this attribute in order to decide if the projects zone must be displayed or not (you can't assign projects to a user if the organization he or she belongs to has no projects at all). The three User's attributes are fetched EAGERly. Now, when changing the user's role from admin to user, the projects zone should be displayed to let me choose projects to be assigned to the user. Instead I see an Ajax error message: Ajax failure: Status 500 for /app/user/edit.role:change: Render queue error in BeginRender[user/Edit:delegate_1]: Failure reading parameter 'to' of component user/Edit:delegate_1: failed to lazily initialize a collection of role: [...].entities.Organization.projects, no session or session was closed And actually, the user.organization.projects field has a null hibernate session property value. I guess that error message is due to the fact that the Organization's projects attribute has no annotated fetch type, and, seemingly, hibernate uses the LAZY one by default. But I can't set that fetch type to EAGER, since otherwise I get a MultipleBagFetchException from hibernate. Now if you've read up to this point I'd surely vote you for president. But before that... any ideas on how to keep the user object contents using solution 1, or to avoid the hibernate exception in solution 2? Thanks (a lot) in advance. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Multizone-updating-and-hibernate-session-loss-tp4936102p4936102.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Multizone updating and hibernate session loss
On Tue, 25 Oct 2011 10:57:21 -0200, Greendog manue...@gmail.com wrote: Hi, everybody. First of all, as a new forum user, I'd like to thank you all for the great job you're doing here. That said, here we go... Hi! This is actually a mailing list, not a forum, but Nabble and maybe some other sites do provide a forum interface over the mailing list. :) EditUser.java (solution 1): I can't see the source. Am I the only one? in BeginRender[user/Edit:delegate_1]: Failure reading parameter 'to' of component user/Edit:delegate_1: failed to lazily initialize a collection of role: [...].entities.Organization.projects, no session or session was closed To avoid that, use Session.merge() before the association is read or sent to the database for updating. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: progressive display
Hi again! For instance: i have a page with the following tml:
t:progressivedisplay t:id=processingWork update=show
initial=block:loadingBlock /
t:block id=loadingBlock
div align=center Working/div
/t:block
t:block id=workErrorBlock
div align=center Error! /div
/t:block
t:block id=workDoneBlock
div align=center Work done! /div
/t:block
And in the java file :
@Inject
private Block workDoneBlock;
@Inject
private Block workErrorBlock;
public Object onProgressiveDisplayFromProcessingWork() {
try {
// working code
return workDoneBlock;
} catch (Exception e) {
return workErrorBlock;
}
}
You can find more info here:
http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/ajax/progressivedisplay
and here:
http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/ajax/progressivedisplayvariations
BR!!
--
David Germán Canteros
2011/10/21 Wechsung, Wulf wulf.wechs...@sap.com
Hi David,
I'm using 5.2.6 as well. What happens when your progressively-displayed
grid can't render and throws an exception?
Best Regards,
Wulf
-Original Message-
From: David Canteros [mailto:davidcanteros@gmail.com]
Sent: Donnerstag, 20. Oktober 2011 18:33
To: Tapestry users
Subject: Re: progressive display
Wich tap version are you using??
I'm doing something like that with grids and it works OK, using tap 5.2.6
BR
--
David Germán Canteros
2011/10/20 Steve Eynon steve.ey...@alienfactory.co.uk
It may be something to do with this (now fixed) Jira :
https://issues.apache.org/jira/browse/TAP5-1706
Try munky patching your tapestry.js page with the suggestion in the
Jira and see if it makes any difference.
Steve.
On 20 October 2011 05:07, Wechsung, Wulf wulf.wechs...@sap.com wrote:
Hello T-User,
I would like to start using the progressive display component to create
the illusion of responsitivity (:) ) but I'm facing the problem that if
anything goes wrong
during the rendering of the P-D's body it will not show an error page
and
instead keeps showing the load animation.
Is there a quick way fix for that?
My component template looks like this:
t:progressivedisplay update=show
t:grid source=systemResults /
/t:progressivedisplay
And my component eventhandler is like this:
@OnEvent(EventConstants.PROGRESSIVE_DISPLAY)
void onProgressiveDisplay() {
... create query etc ...
/** this might take a while ...**/
systemResults = em.createQuery(query).getResultList();
}
The grid rendering fails with a class cast exception because I haven't
provided a proper beanmodel yet. I can see the trace in the console but
the
P-D just keeps loading.
Best Regards,
Wulf
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
property expressions
Hi all,
was hoping someone could point me in the direction on a good tutorial
on the new property expressions in tapestry 5.2.6? I was using OGNL
previously and would like to update these expression to work with
ANTLR instead.
The ognl expression i had was to decorate text field with different
classnames depending on whether the field was null
t:textfield t:id=surname t:value=surname class=${ognl:surname ==
null ? 'touch-and-type' : ''} /
Regards, Brian.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: property expressions
On Tue, 25 Oct 2011 12:14:47 -0200, Brian Long bl...@annadaletech.com
wrote:
Hi all,
Hi!
was hoping someone could point me in the direction on a good tutorial
on the new property expressions in tapestry 5.2.6?
http://tapestry.apache.org/property-expressions.html
I was using OGNL
previously and would like to update these expression to work with
ANTLR instead.
What do you mean by to update these expression to work with ANTLR? I'm
not following you. And don't forget that you can add your own binding
implementations in Tapestry. prop (property expressions) is just one of
them.
t:textfield t:id=surname t:value=surname class=${ognl:surname ==
null ? 'touch-and-type' : ''} /
Easy:
t:textfield t:id=surname t:value=surname class=${surnameCssClass}/
public String getSurnameCssClass() {
return surname == null ? 'touch-and-type' : '';
}
Logic should be on Java classes, not templates. That's the Tapestry 5
philosophy (MVC's too).
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: property expressions
In Tapestry 4, we shifted a lot of logic into OGNL because that was
the only logic that could be reloaded (with the template) at runtime,
during development. This was good in some ways, OGNL is still more
versatile than Tapestry 5's property expressions, but came at a huge
cost in terms of reflection overhead and a few highly contested code
paths that tended to serialize the application.
In Tapestry 5, you tend to reference a property from your template, as
Thiago pointed out. Both the template and the Java code reload
instantly, and the separation makes each part a bit cleaner.
On Tue, Oct 25, 2011 at 7:46 AM, Thiago H. de Paula Figueiredo
thiag...@gmail.com wrote:
On Tue, 25 Oct 2011 12:14:47 -0200, Brian Long bl...@annadaletech.com
wrote:
Hi all,
Hi!
was hoping someone could point me in the direction on a good tutorial
on the new property expressions in tapestry 5.2.6?
http://tapestry.apache.org/property-expressions.html
I was using OGNL
previously and would like to update these expression to work with
ANTLR instead.
What do you mean by to update these expression to work with ANTLR? I'm not
following you. And don't forget that you can add your own binding
implementations in Tapestry. prop (property expressions) is just one of
them.
t:textfield t:id=surname t:value=surname class=${ognl:surname ==
null ? 'touch-and-type' : ''} /
Easy:
t:textfield t:id=surname t:value=surname class=${surnameCssClass}/
public String getSurnameCssClass() {
return surname == null ? 'touch-and-type' : '';
}
Logic should be on Java classes, not templates. That's the Tapestry 5
philosophy (MVC's too).
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Multizone updating and hibernate session loss
Thiago H de Paula Figueiredo wrote: Hi! This is actually a mailing list, not a forum, but Nabble and maybe some other sites do provide a forum interface over the mailing list. :) You're right. I was using Nabble's. Thiago H de Paula Figueiredo wrote: EditUser.java (solution 1): I can't see the source. Am I the only one? I just included a field and a couple of event managers in my message, trying not to make it too extense. I guess I omitted relevant parts, so here is the full page class source code: -- View this message in context: http://tapestry.1045711.n5.nabble.com/Multizone-updating-and-hibernate-session-loss-tp4936102p4936906.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: property expressions
Hi Thiago,
thanks for the quick reply, I'd already seen the official tapestry
property expressions page but as there's no examples given there I was
hoping there was something else buried in one of the wiki pages?
I'll take your advise and move this logic to the java class, I'm going
to have a lot of helper methods for the logic that was attached to the
various fields on my form, but I guess I can't be avoided.
Regards, Brian.
On 25 October 2011 14:46, Thiago H. de Paula Figueiredo
thiag...@gmail.com wrote:
On Tue, 25 Oct 2011 12:14:47 -0200, Brian Long bl...@annadaletech.com
wrote:
Hi all,
Hi!
was hoping someone could point me in the direction on a good tutorial
on the new property expressions in tapestry 5.2.6?
http://tapestry.apache.org/property-expressions.html
I was using OGNL
previously and would like to update these expression to work with
ANTLR instead.
What do you mean by to update these expression to work with ANTLR? I'm not
following you. And don't forget that you can add your own binding
implementations in Tapestry. prop (property expressions) is just one of
them.
t:textfield t:id=surname t:value=surname class=${ognl:surname ==
null ? 'touch-and-type' : ''} /
Easy:
t:textfield t:id=surname t:value=surname class=${surnameCssClass}/
public String getSurnameCssClass() {
return surname == null ? 'touch-and-type' : '';
}
Logic should be on Java classes, not templates. That's the Tapestry 5
philosophy (MVC's too).
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: property expressions
On Tue, 25 Oct 2011 14:57:50 -0200, Brian Long bl...@annadaletech.com wrote: Hi Thiago, Hi! thanks for the quick reply, I'd already seen the official tapestry property expressions page but as there's no examples given there I was hoping there was something else buried in one of the wiki pages? I don't know any just by taking a look by memory. Have you taken a look at Tapestry JumpStart? I'll take your advise and move this logic to the java class, I'm going to have a lot of helper methods for the logic that was attached to the various fields on my form, but I guess I can't be avoided. Nice. :) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Mixins stop working after a zone update (please help)
When you get the ajax response back, did any of ids change? The stuff in the zone changes but the javascript code from the mixin doesn't . I am not an expert but thats the only thing I can think of. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Mixins-stop-working-after-a-zone-update-please-help-tp4935912p4937058.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Mixins stop working after a zone update (please help)
Yes, the changing of the client IDs to semi-random ones was what I suspected before (hence my previous thread) but after some debugging, it turns out that the mixin gets initialized after the zone update with the new client IDs correctly and something else is going on. It seems like the AJAX event from the mixin to the server stops working, i.e. onsubmit() winds up doing a no-op even though JS calls the server with the form. On Oct 25, 2011, at 1:26 PM, cqasker wrote: When you get the ajax response back, did any of ids change? The stuff in the zone changes but the javascript code from the mixin doesn't . I am not an expert but thats the only thing I can think of. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Mixins stop working after a zone update (SOLVED!)
There was an addition of one line:
$(this.formId).setSubmittingElement($(this.elementId)); // *** ADDED otherwise
zone gets improperly reloaded
$(this.formId).onsubmit(); // Submit Ajax form
If you don't add the first line, the form is reloaded improperly after the zone
update,
so it doesn't work the second time.
*** This is not documented anywhere, and really hard to debug.
This needs to be incorporated into the JumpStart, because it's now broken there.
- FIXED CODE --
/**
* Disable Submit button after AJAX Form Submission
*/
var DisableAfterSubmit = Class.create();
DisableAfterSubmit.prototype = {
initialize: function(elementId, formId, event) {
this.formId = formId;
this.elementId = elementId;
this.handler = this.doEnable.bindAsEventListener(this);
Event.observe($(elementId), 'click',
this.doDisable.bindAsEventListener(this));
},
doDisable: function() {
$(this.elementId).disable();
if($(this.formId).getStorage().zoneId != null) {
this.zoneElement = Tapestry.findZoneManager(this.formId).element;
Event.observe(this.zoneElement, Tapestry.ZONE_UPDATED_EVENT,
this.handler);
$(this.formId).setSubmittingElement($(this.elementId));
$(this.formId).onsubmit();
}
else {
$(this.formId).submit();
}
},
doEnable: function() {
$(this.zoneElement).stopObserving(Tapestry.ZONE_UPDATED_EVENT,
this.handler);
var element = $(this.elementId);
if(element != null) {
$(this.elementId).enable();
}
}
};
// Extend the Tapestry.Initializer with a static method that instantiates us
Tapestry.Initializer.disableAfterSubmit = function(spec) {
new DisableAfterSubmit(spec.elementId, spec.formId);
};
On Oct 25, 2011, at 2:12 PM, Lenny Primak wrote:
Yes, the changing of the client IDs to semi-random ones was what I suspected
before
(hence my previous thread)
but after some debugging, it turns out that the mixin gets initialized
after the zone update with the new client IDs correctly
and something else is going on.
It seems like the AJAX event from the mixin to the server stops working,
i.e. onsubmit() winds up doing a no-op even though JS calls the server with
the form.
On Oct 25, 2011, at 1:26 PM, cqasker wrote:
When you get the ajax response back, did any of ids change? The stuff in the
zone changes but the javascript code from the mixin doesn't . I am not an
expert but thats the only thing I can think of.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Mixins stop working after a zone update (SOLVED!)
This ties into where I expect Tapestry to be heading in 5.4, where you
care less about what the component ids are, and more about structure
(including CSS selectors) that filter up to event handlers on the body
element; it means Tapestry can get out of the business of
micro-managing event handlers ... I'm still thinking about this, and
will be blogging about this direction soon.
On Tue, Oct 25, 2011 at 4:22 PM, Lenny Primak lpri...@hope.nyc.ny.us wrote:
There was an addition of one line:
$(this.formId).setSubmittingElement($(this.elementId)); // *** ADDED
otherwise zone gets improperly reloaded
$(this.formId).onsubmit(); // Submit Ajax form
If you don't add the first line, the form is reloaded improperly after the
zone update,
so it doesn't work the second time.
*** This is not documented anywhere, and really hard to debug.
This needs to be incorporated into the JumpStart, because it's now broken
there.
- FIXED CODE --
/**
* Disable Submit button after AJAX Form Submission
*/
var DisableAfterSubmit = Class.create();
DisableAfterSubmit.prototype = {
initialize: function(elementId, formId, event) {
this.formId = formId;
this.elementId = elementId;
this.handler = this.doEnable.bindAsEventListener(this);
Event.observe($(elementId), 'click',
this.doDisable.bindAsEventListener(this));
},
doDisable: function() {
$(this.elementId).disable();
if($(this.formId).getStorage().zoneId != null) {
this.zoneElement = Tapestry.findZoneManager(this.formId).element;
Event.observe(this.zoneElement, Tapestry.ZONE_UPDATED_EVENT,
this.handler);
$(this.formId).setSubmittingElement($(this.elementId));
$(this.formId).onsubmit();
}
else {
$(this.formId).submit();
}
},
doEnable: function() {
$(this.zoneElement).stopObserving(Tapestry.ZONE_UPDATED_EVENT,
this.handler);
var element = $(this.elementId);
if(element != null) {
$(this.elementId).enable();
}
}
};
// Extend the Tapestry.Initializer with a static method that instantiates us
Tapestry.Initializer.disableAfterSubmit = function(spec) {
new DisableAfterSubmit(spec.elementId, spec.formId);
};
On Oct 25, 2011, at 2:12 PM, Lenny Primak wrote:
Yes, the changing of the client IDs to semi-random ones was what I suspected
before
(hence my previous thread)
but after some debugging, it turns out that the mixin gets initialized
after the zone update with the new client IDs correctly
and something else is going on.
It seems like the AJAX event from the mixin to the server stops working,
i.e. onsubmit() winds up doing a no-op even though JS calls the server with
the form.
On Oct 25, 2011, at 1:26 PM, cqasker wrote:
When you get the ajax response back, did any of ids change? The stuff in the
zone changes but the javascript code from the mixin doesn't . I am not an
expert but thats the only thing I can think of.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Mixins stop working after a zone update (SOLVED!)
Yes, anything that will get me out of the JavaScript business! I just started dealing with it and I am getting to despise it! On Oct 25, 2011, at 8:30 PM, Howard Lewis Ship wrote: This ties into where I expect Tapestry to be heading in 5.4, where you care less about what the component ids are, and more about structure (including CSS selectors) that filter up to event handlers on the body element; it means Tapestry can get out of the business of micro-managing event handlers ... I'm still thinking about this, and will be blogging about this direction soon. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: An Appeal To Use the Latest Betas
I am running into a problem getting the betas using maven and nexus. My setup is that everything points to my instance of nexus and it in turn points to all the other repositories. I have setup a Release proxy and a Snapshot proxy both pointing to: https://repository.apache.org/content/groups/staging/ For some reason the betas are not showing up in either repository. They are showing up when I browse the remote from within my instance of nexus, but when I click over to browse the index they aren't there. It is almost as if the betas are getting put in the right directory, but the index is not being updated. Another theory is that these betas are being marked as a SNAPSHOT so they don't show up in the Release index, but aren't following the Snapshot naming convention so they don't show up there either. Has anyone run into any similar issues or have any suggestion? Mark On Thu, Oct 13, 2011 at 6:16 PM, Howard Lewis Ship hls...@gmail.com wrote: If you've been following the discussions here and elsewhere, you may be aware that Tapestry 5.3 is nearly done, with big improvements to every aspect of Tapestry, including speed and memory utilization. Our goal is to deliver an upgrade that is as seamless as possible. The PMC would dearly like to get a final release out and available before December (that is, within one year of the release 5.2). However, we can't do it without YOU: We need people actively using Tapestry to upgrade to the latest betas (5.3-beta-20 is the latest, but we're releasing new updates almost every day). We are looking for broken features or problems upgrading ... all the things that will get in the way of a release candidate and then a final release. Your feedback is essential ... without are community, we don't know for sure that Tapestry is ready to go to the next stage. Please budget some time, as soon as possible, to run you application under 5.3 and report back here about any problems you find. Without accurate (and hopefully, positive) feedback, we will not be able to progress to a final release ... and that means we'll be delayed adding the next layer of amazing features in Tapestry 5.4! Please see these notes on how to make use of the latest beta preview releases: http://tapestry.apache.org/2011/08/27/tapestry-53-beta-preview.html http://tapestryjava.blogspot.com/2011/10/tapestry-53-maven-archetype.html I've been posing on twitter each time a new preview is made available: http://twitter.com/#!/search/%23tapestry5 ... and note that by the time you do you upgreade, the exact version number may have changed (don't worry, beta-20 will still be available when beta-21 is made available). Your support is deeply appreciated ... now get back to coding less and delivering more! -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
