/app/page:anyEvent => will fire an event named "anyEvent" on the Page.
This method returns void.
At the end of this event, tapestry issues redirect, and rendering should
happen in that request.
And you are correct that I don't see this URL and I see the final redirected
page URL.
In the above scenario, i would just need to patch up the markupRenderer
configuration.. and where else?
More confusing is why should it behave inconsistently? It works few times
and then it fails.. once fails, it fails forever...
And in the log file, i can see clearly it is going thru DocumentLinkerImpl
and not my custom documentlinker.
java.lang.RuntimeException: The root element of the rendered document was
<div>, not <html>. A root element of <html> is needed when linking
JavaScript and stylesheet resources.
at
org.apache.tapestry5.internal.services.DocumentLinkerImpl.addScriptElements(DocumentLinkerImpl.java:99)
at
org.apache.tapestry5.internal.services.DocumentLinkerImpl.updateDocument(DocumentLinkerImpl.java:85)
at
org.apache.tapestry5.services.TapestryModule$25.renderMarkup(TapestryModule.java:1499)
Thanks for spending your time on figuring out this issue.
Fernando Padilla wrote:
>
> 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
>
>
>
--
View this message in context:
http://n2.nabble.com/How-to-override-Tapestry%27s-DocumentLinker---tp2239793p2259957.html
Sent from the Tapestry Users 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
