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
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:
Nice one, Thiago. https://issues.apache.org/jira/browse/TAP5-2301.
On 15/03/2014, at 4:51 AM, Thiago H de Paula Figueiredo wrote:
On Thu, 13 Mar 2014 23:32:55 -0300, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
To all Tapestry devs,
Hi!
I agree with you. That's one of
Chris,
In case you haven't seen it, I explored some of the issues of Grid, filtering,
and AJAX here:
http://jumpstart.doublenegative.com.au/jumpstart7/together/ajaxcomponentscrud/persons
Don't know if there are any useful ideas in there for you.
Geoff
On 14/03/2014, at 8:15 PM,
It's probably worth mentioning my onevent mixin here.
http://tapestry-stitch.uklance.cloudbees.net/oneventdemo
Sorry to toot my own horn but I think it greatly simplifies many ajax
interactions. It not only allows a context to be passed but it can also
send a list of clientside field values in
Yes, I think it should be part of tapestry core.
As a nod to jquery you could simply call it on :-)
On 15/03/2014, at 6:39 PM, Lance Java wrote:
It's probably worth mentioning my onevent mixin here.
http://tapestry-stitch.uklance.cloudbees.net/oneventdemo
Sorry to toot my own horn but I
Yes, I think it should be part of tapestry core.
Unfortunately it clashes a bit with the zone parameter in select. Does
anybody support making a breaking change to remove the ajax behaviour from
select if this mixin was added to core?
As a nod to jquery you could simply call it on :-)
Yeah, I
You are absolutely right. Context for Select and Grid would be a welcome
addition. Even though these are only scaffolding components that are meant
to be extended and modified to fit your use cases, most people use them as
they are. There may be some other components that need this addition, but
Hi,
This is a well timed discussion ;-)
I've been spending some time creating a grid version that supports
filtering and not uses @Persist internally. I have been forced to create a
new Select to get context support, I've decided not to create context
support for the grid until it is actually
I'd agree with context for the Grid component, though the only use-case I
see for Grid's context is for paging event links, and it'd be nice and easy
to support this.
But Select component must be put into a Form, and forms have contexts, so I
see no problems here.
I don't think one should avoid
Dimitry, how can we get a hold of the form context in the onValueChanged
handler for Select? (zone/ajax case)
--
Chris
On Fri, Mar 14, 2014 at 10:16 AM, Dmitry Gusev dmitry.gu...@gmail.comwrote:
I'd agree with context for the Grid component, though the only use-case I
see for Grid's context
Oh, I see you what you mean now, there's eventLink that triggers
Select#onChange for ajax selects and it doesn't include any context in the
link. Makes sense.
On Fri, Mar 14, 2014 at 1:31 PM, Chris Poulsen mailingl...@nesluop.dkwrote:
Dimitry, how can we get a hold of the form context in the
I think column sorting also needs to pass context if, for instance, you're
using a paged, filtered, GridDataSource. Without a context it might not build
the next page correctly.
Bookmarking is a different issue, that I don't yet have a good solution for.
For example, every EventLink has the
Right, actually every eventLink that is inside of core component should
support context so that server-side could restore some state on request.
On Fri, Mar 14, 2014 at 5:01 PM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
I think column sorting also needs to pass context if,
I'm not sure about changing page context, but I'd suppose that if page
context changed - then page URL should reflect that, and you have to reload
the page -- and that is usually with HTTP 3xx redirect. You can't just
change the URL in browser's address bar without reloading entire page. One
On Thu, 13 Mar 2014 23:32:55 -0300, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
To all Tapestry devs,
Hi!
I agree with you. That's one of the first things I want to do when I go
back to work on the Month of Tapestry. Please file a JIRA. And thanks for
bringing that up.
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
17 matches
Mail list logo
