See that's the weird part..
1) render page form:
/myapp/page1
2) submit form:
/myapp/page1.form:action
3) form handles submit(fail or success),
then returns redirect to render page:
redirect:/myapp/page1
4) page 1 is rendered once more.
So I'm a little confused.. since you mention another event?
What does your "editMe" event handler method return? null? A block? a
page name? It should also cause a full redirect to render the full page
( so you should never see that url in the browser ).
Dude.Checkitout wrote:
Thanks for the reply!
I see there only two render pipelines in the TapestryModule.java. One is
contributeMarkupRenderer and another one is contributePartialMarkupRenderer.
PartialMarkupRenderer uses "PartialMarkupDocumentLinker" as the Document
Linker. And PartialMarkupDocumentLinker generates output as JSON. Does not
validate against any root html nodes.
So my assumption was I shouldn't be needing to touch that part of rendering.
Correct me if I am wrong.
We do use redirect after post modal. The page which gives errors is
invoking a specific event on the page in the URL to load the page which has
form.
Example URL: /myapp/page1:editMe/somekeyvalue
Is this request a action request or render request? Which renderes will it
use? My assumption is that this is an action event request and it will just
invoked that event in the page and issue a redirect.
Am I missing any renderer? or which is the "other" renderer that I need to
patch up?
Fernando Padilla wrote:
Sorry for the wait. I don't have the final answer for you, but I do
have information to share.. :)
I think it'll be the same technique of overriding tapestry's document
linker, but there are two render pipelines, so you have to find the
correct place to contribute..
Don't forget that Tapestry has two request handling pipelines. One for
normal page request. And another for component events (like form
submits) or ajax call backs (like zones). Most likely the code that we
worked out before only covered normal page renders. But somehow you're
hitting the component event handling oversight..
The reason that i would normally not be an issue, is that component
events normally do not do any rendering, they simply send back a
redirect asking the client to request the full page, and then causing a
clean page render.. (do yo understand this point?)
That is how I have it working, and probably why I did not have to deal
with it before and give you a warning. You probably have tapestry setup
to render the page on the same request as the form submits ( instead of
returning a redirect ).
Is this enough info to get you started hunting?
Dude.Checkitout wrote:
Fernando, need your expertise help! I thought the following trick
configuration.add( "CustomDocumentLinker", mydoclinker,
"after:DocumentLinker,before:RenderSupport" );
worked.
Looks like it is not working in all conditions. It runs fine for a while,
then out of nowhere I start getting the same root <html> required error.
The strange (may be for me) thing I observed is, it fails only on pages
which has Tapestry forms.
(we have read only/display version of pages - which seems to work fine in
all cases).
Once it starts giving this root <html> error, the whole application
reports
the same error. (all pages which has tapestry form in it). FYI, I have
more than one tapestry application running on the same JBoss server. Just
curious, if it messes up things.
I am stuck and any help would be greatly appreciated!
Fernando Padilla wrote:
yah, this is little confusing, since it will place the CustomLinker
first in the list of filters.. :) But they "execute" as they come out
of the list.. :)
CustomLinker -> DocumentLinker -> RenderSupport -> PAGERENDER
So as the page render unfurls, it gives control to RenderSupport to
modify the DOM, then DocumentLinker, then CustomLinker. And the
document linkers really don't do anything by themselves, and require a
RenderSupport to feed them the script/css links. So the RenderSupport
filter would call environment.peekRequired(DocumentLinker.class), which
would return the deepest DocumentLinker at the moment (the default, not
the Custom one)..
So yeah a little confusing.. :) :)
Thiago H. de Paula Figueiredo wrote:
Em Thu, 29 Jan 2009 15:14:40 -0300, Fernando Padilla
<f...@alum.mit.edu>
escreveu:
No. DocumentLinker would be run first ( deeper in the markup filter
chain ), it would be the only one that RenderSupport would bind to (
RenderSupport does a environment.peekRequired ). So only that
DocumentLinker would do it's stuff.
Even when the custom document linker is explicitly added to the
OrderedConfiguration *before* the normal DocumentLinker? If yes, well,
the contribution overriding mechanism in T5.1 will be extra handy . . .
:)
---------------------------------------------------------------------
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
