Fix versions for 5.4?
Related to TAP5-2214, should we create a new 5.4.0 version in JIRA (who's got the karma?) or what's the plan for setting fix version for defects found in 5.4 beta release? Kalle
Re: Fix versions for 5.4?
I've just been doing affects 5.4, fixed in 5.4. If there's a pressing need, we could augment this with an agreed-upon tag, e.g. found-in-5.4-beta. On Tue, Mar 25, 2014 at 10:25 AM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: Related to TAP5-2214, should we create a new 5.4.0 version in JIRA (who's got the karma?) or what's the plan for setting fix version for defects found in 5.4 beta release? Kalle -- 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
Re: Discussion on all AJAX requests needing context
I would definitely agree that Tapestry has a problem dealing with complex
Ajax pages. Essentially, for Tapestry to do the right thing, it has to
have a model of what's going on in the client browser and no such model
exists.
Passing a page context and an individual event context helps, but you start
getting into scenarios where there's a context for the Zone and a context
for the link/form inside the Zone.
Past a certain point, it simply feels like we're trying to plug the holes
in the leaky dike.
I think the correct way forwards is to say that Tapestry's built-in Ajax
support is great for simple to low-moderate complexity ... but if you are
doing something very dynamic, it is not the best approach. Moving complex
UI logic to the client is the right approach, and the challenge is to
figure out how to move Tapestry and it's community in that direction.
On Thu, Mar 13, 2014 at 7:32 PM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
To all Tapestry devs,
Please, I want your thoughts before I file a JIRA, just in case I have my
wires crossed.
I'm thinking that Tapestry has real problems working with complex AJAX
pages because there are AJAX components that don't have a context
parameter.
The problem I see is that a deeply nested component, C, cannot handle an
event from an AJAX sub-component unless C can reconstruct its context, ie.
C has to be able to restore its parameters. This has been solved in Form
and EventLink by giving them a context parameter. eg.
onPrepareForSubmit(Integer contextArg1) { etc. }
onMyevent(Integer contextArg1) { etc. }
I routinely use this context to restore C's parameters, eg.
@Parameter
private Integer parameter1;
onPrepareForSubmit(Integer parameter1) {
this.parameter1 = parameter1;
}
But what about Select and Grid? Neither of them has a context.
Without a context, C can't handle 2 or more AJAX Select components. When
one sends an event, C has no idea of the value of the other, nor of its own
parameters. A context would fix all of this.
Without a context, an inplace request from a GridPager can't remind C was
currently selected or how the Grid was being filtered. The same goes for
Grid column select events. (See
https://issues.apache.org/jira/browse/TAP5-2297)
There are workarounds, but with a context I think we wouldn't need them:
1. Use @Persist. Well, we all try to avoid this.
2. Include C's parameters in the page's context and make sure they're
passed down through every nested component down to C. But surely that's not
reasonable. What if the page is concerned with a Hospital, but in it our
components drill down through a Ward to a Patient and C is concerned with
the Patient's Diagnosis. Does it really make sense to pass diagnosisId in
through the page context and down through all the in-between components?
Following this logic, we could end up with every parameter of every
component in the page context.
3. Use activation request parameters, but it appears to me to be messy.
@ActivationRequestParameters is only available at the page level, so again
we have to pass them all the way down. Even if we do this, it's a nuisance
to pass them all the way UP in the first place. And again we could end up
with every parameter of every component being declared in the page.
4. Perhaps C can get and set request parameters by hand, but why? Isn't a
context better?
Am I seeing an issue that doesn't exist? Is there a better way?
Cheers,
Geoff
--
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
Re: Fix versions for 5.4?
Ok. Not pressing, just harder to see what's fixed since the last beta release. Kalle On Tue, Mar 25, 2014 at 10:58 AM, Howard Lewis Ship hls...@gmail.comwrote: I've just been doing affects 5.4, fixed in 5.4. If there's a pressing need, we could augment this with an agreed-upon tag, e.g. found-in-5.4-beta. On Tue, Mar 25, 2014 at 10:25 AM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: Related to TAP5-2214, should we create a new 5.4.0 version in JIRA (who's got the karma?) or what's the plan for setting fix version for defects found in 5.4 beta release? Kalle -- 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
Re: Discussion on AJAX requests need even more than a context?
Sorry, but I've read the solution below 10 times now and it hurts my head every
time! :-) I don't see how it gets around the problem that when E is
AJAX-submitted, the server-side elements can find ways to prod L to refresh but
they cannot tell L the current value of F. The server-side doesn't know the
current value of F, unless we make the server-side stateful (no thank you), or
we somehow include the value of F in every request.
What I'm aiming for is a solution which works declaratively. You know, where
you don't see the plumbing. Just like @ActivationRequestParameter, but at the
component level.
On 21/03/2014, at 2:35 AM, Lance Java wrote:
I'm imagining the pub sub would work like...
public class L {
@Inject
private Publisher publisher;
@Inject
private Block someBlock;
/**
* Fired when the select menu changes
*/
public Object onFilterChange(Entity entity) {
publisher.publish(changeEntity, entity);
return someBlock;
}
}
public class E {
@Inject
private AjaxResponseRenderer ajaxResponseRenderer;
@Inject
private Zone someZone;
@Property
private Entity entity;
@Subscribe(topic=changeEntity)
void subscribeChangeEntity(Entity entity) {
this.entity = entity;
ajaxResponseRenderer.addRender(someZone;
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Discussion on all AJAX requests needing context
Agreed, but I think Tapestry can go a big step towards to handling more AJAX
cases without that. Howard, could you comment on this other discussion:
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Discussion-on-AJAX-requests-need-even-more-than-a-context-tt5726230.html
On 26/03/2014, at 5:03 AM, Howard Lewis Ship wrote:
I would definitely agree that Tapestry has a problem dealing with complex
Ajax pages. Essentially, for Tapestry to do the right thing, it has to
have a model of what's going on in the client browser and no such model
exists.
Passing a page context and an individual event context helps, but you start
getting into scenarios where there's a context for the Zone and a context
for the link/form inside the Zone.
Past a certain point, it simply feels like we're trying to plug the holes
in the leaky dike.
I think the correct way forwards is to say that Tapestry's built-in Ajax
support is great for simple to low-moderate complexity ... but if you are
doing something very dynamic, it is not the best approach. Moving complex
UI logic to the client is the right approach, and the challenge is to
figure out how to move Tapestry and it's community in that direction.
On Thu, Mar 13, 2014 at 7:32 PM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
To all Tapestry devs,
Please, I want your thoughts before I file a JIRA, just in case I have my
wires crossed.
I'm thinking that Tapestry has real problems working with complex AJAX
pages because there are AJAX components that don't have a context
parameter.
The problem I see is that a deeply nested component, C, cannot handle an
event from an AJAX sub-component unless C can reconstruct its context, ie.
C has to be able to restore its parameters. This has been solved in Form
and EventLink by giving them a context parameter. eg.
onPrepareForSubmit(Integer contextArg1) { etc. }
onMyevent(Integer contextArg1) { etc. }
I routinely use this context to restore C's parameters, eg.
@Parameter
private Integer parameter1;
onPrepareForSubmit(Integer parameter1) {
this.parameter1 = parameter1;
}
But what about Select and Grid? Neither of them has a context.
Without a context, C can't handle 2 or more AJAX Select components. When
one sends an event, C has no idea of the value of the other, nor of its own
parameters. A context would fix all of this.
Without a context, an inplace request from a GridPager can't remind C was
currently selected or how the Grid was being filtered. The same goes for
Grid column select events. (See
https://issues.apache.org/jira/browse/TAP5-2297)
There are workarounds, but with a context I think we wouldn't need them:
1. Use @Persist. Well, we all try to avoid this.
2. Include C's parameters in the page's context and make sure they're
passed down through every nested component down to C. But surely that's not
reasonable. What if the page is concerned with a Hospital, but in it our
components drill down through a Ward to a Patient and C is concerned with
the Patient's Diagnosis. Does it really make sense to pass diagnosisId in
through the page context and down through all the in-between components?
Following this logic, we could end up with every parameter of every
component in the page context.
3. Use activation request parameters, but it appears to me to be messy.
@ActivationRequestParameters is only available at the page level, so again
we have to pass them all the way down. Even if we do this, it's a nuisance
to pass them all the way UP in the first place. And again we could end up
with every parameter of every component being declared in the page.
4. Perhaps C can get and set request parameters by hand, but why? Isn't a
context better?
Am I seeing an issue that doesn't exist? Is there a better way?
Cheers,
Geoff
--
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: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
