[TYPO3-mvc] Request does not end

Lorenz Ulrich lorenz-typo3 at visol.ch
Tue Feb 21 10:43:54 CET 2012


Hi Dirk

Don't know what way you are using the tabs (dynamically loaded content 
or pre-loaded), but to me it sounds like an absRefPrefix problem.

Since it's clearly no Extbase problem, you could move the discussion 
out? I have JQuery UI Tabs working (with baseUrl, without absRefPrefix) 
properly in an Extbase extension. Storing/validating works and thanks to 
JQuery Cookie the user is back on the last opened Tab after saving.

If you can provide more details on your setup, I might give you some 
help fixing that.

Lorenz

Am 21.02.2012 10:32, schrieb Dirk Rauscher:
> Hi Henjo,
>
> I went through the code again and found a soluttion for the problem.
>
> As you assumed correctly the javascript code altered the form code. Now
> I did a little hack in the js framework to avoid this bahaviour. Not the
> most elegant way... but it works.
>
> Explaination:
>
> I use jquery framework 1.7.1, UI 1.8.17 to generate a tabbed form.
>
> In $.widget("ui.tabs") there is the function _tabify() which is
> responsible for building the panels and tabs from some defined a-tags.
> The loop this.anchors.each(function(i,a))... iterates through the a-tags
> and generates the appropriate tabs.
> For some reason the line
> var href = $(a).attr("href");
> returns a full url instead of the section anchor. This url points to the
> updateAction of my Extension. The jquery framework then tries to load
> the content of the panel through an ajax call and leads to a exception.
>
> Now I changed the line to
> var href = a.href;
> and the returned value is what it should be -> the section anchor.
> The tab content isn't loaded through a wrong ajax call any longer.
>
>
> Maybe there is another solution for that problem that is more elegant.
>
>
> Kind regards,
>
> Dirk
>
>
>
> Am 19.02.2012 08:42, schrieb Henjo Hoeksma:
>> Hi Dirk,
>>
>> little in the dark here, sorry. Just to make sure:
>> with the tabs feature off -> everything works fine?
>>
>> If that's the case, the tabs function does something that alters your
>> form
>> code and most-likely strips some code in the hidden form parts.
>>
>> Kind regards,
>>
>> Henjo
>>
>> Problems are small because we learned how to deal with them.
>> Problems are big because we need to learn how to deal with them.
>>
>>
>> On Fri, Feb 17, 2012 at 12:20, Dirk
>> Rauscher<dr_typo3 at itb-institut.de>wrote:
>>
>>> Hi Henjo,
>>>
>>> thanks for you reply.
>>>
>>>
>>>> Shouldn't you bind the call's you do in your javascript events?
>>>
>>> I don't see the meaning of your question. The calls that can be done in
>>> this form are 'save' and 'cancel' and both are handled by the form's
>>> submit
>>> button respectively a link. The only thing the javascript does is to
>>> split
>>> up the form's fields into tabs.
>>>
>>> I think it is somethin in the extbase code as I found this:
>>>
>>> My newAction and editAction both use identical templates (same formfield
>>> partial, javascript etc.) and they are for creating/editing a person.
>>>
>>> Example:
>>>
>>> When creating a new person it goes like this:
>>> ------------------------------**---------------------
>>> ++ calling newAction --> renderForm
>>> ++ filling the form with invalid data and klick submit
>>> ++ calling createAction --> validate the submitted person-object
>>> ++ calling errorAction --> forward to __referrer(newAction)
>>> ++ renderForm --> END
>>>
>>>
>>> But when editing an existing person this happens:
>>> ------------------------------**---------------------
>>> ++ calling editAction --> renderForm
>>> ++ filling the form with invalid data and klick submit
>>> ++ calling updateAction --> validate the submitted person-object
>>> ++ calling errorAction --> forward to __referrer(editAction)
>>> ++ renderForm
>>>
>>> ++ calling errorAction --> return error message (no forward because no
>>> __referrer is given)
>>>
>>>
>>> I can't see where the different lies. Removing all php code from the
>>> updateAction or createAction doesn't cause any difference. The
>>> php-code in
>>> newAction and editAction is equal.
>>>
>>> Any suggestions...?
>>>
>>>
>>> Kind regards, Dirk
>>>
>>>
>>> Am 16.02.2012 00:40, schrieb Henjo Hoeksma:
>>>
>>>> I don't think this is an Extbase issue.
>>>> Shouldn't you bind the call's you do in your javascript events?
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Henjo
>>>>
>>>> Problems are small because we learned how to deal with them.
>>>> Problems are big because we need to learn how to deal with them.
>>>>
>>>>
>>>> On Wed, Feb 15, 2012 at 16:34, Dirk
>>>> Rauscher<dr_typo3 at itb-**institut.de<dr_typo3 at itb-institut.de>
>>>>> wrote:
>>>>
>>>> I encounter a strange behaviour in using t3jquery with my extbase
>>>>> extension.
>>>>>
>>>>> I generate a form whose fields are distributed over 4 Tabs. For that I
>>>>> use
>>>>> a jQuery function tabs() in my Fluid Template.
>>>>>
>>>>> jQuery(document).ready(****function(){
>>>>>
>>>>> jQuery("#theTabs").tabs();
>>>>>> });
>>>>>>
>>>>>>
>>>>> On the first call of editAction the form is rendered properly. If the
>>>>> form
>>>>> is filled out in an incorrect way and the save button is clicked, the
>>>>> updateAction is called. The defined annotations in updateAction
>>>>> recognizes
>>>>> a invalid object and calls errorAction. From there errorAction
>>>>> returns to
>>>>> the __referrer --> editAction.
>>>>>
>>>>> So far everything is ok, but instead of ending the request and
>>>>> rendering
>>>>> the editAction template, the updateAction is called again!
>>>>>
>>>>> When I debug request->getArguments() there is nothing in except for
>>>>> the
>>>>> keys [action] and [controller].
>>>>>
>>>>> If I deactivate javascript support in my browser everything's ok
>>>>> and the
>>>>> request ends up after errorAction returns to the __referrer.
>>>>>
>>>>> How can I get rid of this behaviour? Is it a bug?
>>>>>
>>>>> Any help is gratefully appreciated.
>>>>>
>>>>> Dirk
>>>>> ______________________________****_________________
>>>>> TYPO3-project-typo3v4mvc mailing list
>>>>> TYPO3-project-typo3v4mvc@**lis**ts.typo3.org<http://lists.typo3.org><
>>>>> TYPO3-project-**typo3v4mvc at lists.typo3.org<TYPO3-project-typo3v4mvc at lists.typo3.org>
>>>>>
>>>>>>
>>>>> http://lists.typo3.org/cgi-****bin/mailman/listinfo/typo3-**<http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-**>
>>>>>
>>>>> project-typo3v4mvc<http://**lists.typo3.org/cgi-bin/**
>>>>> mailman/listinfo/typo3-**project-typo3v4mvc<http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-project-typo3v4mvc>
>>>>>
>>>>>>
>>>>>
>>>>>
>>> ______________________________**_________________
>>> TYPO3-project-typo3v4mvc mailing list
>>> TYPO3-project-typo3v4mvc@**lists.typo3.org<TYPO3-project-typo3v4mvc at lists.typo3.org>
>>>
>>> http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-**
>>> project-typo3v4mvc<http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-project-typo3v4mvc>
>>>
>>>
>



More information about the TYPO3-project-typo3v4mvc mailing list