CoreCommunity ExtensionsIncubatorDistributionsTYPO3 4.5 ProjectsTYPO3 4.6 ProjectsTYPO3 4.7 ProjectsTYPO3 6.0 ProjectsTYPO3 6.1 ProjectsTYPO3 6.2 Projects (+)

Support #31095

Accessing intercepted values in Conditions

Added by Rainer Becker over 1 year ago. Updated over 1 year ago.

Status:Resolved Start date:2011-10-19
Priority:Should have Due date:
Assignee:Reinhard Führicht % Done:

100%
Category:-
Target version:Stable v1.0
Votes: 0

Description

In my interceptor I add some calculated values to gp. It seems that conditions are handled before interceptors, so I can’t used these complex values for conditions. Is there a way to create custom conditions (PHP)?

31095.patch (799 Bytes) Reinhard Führicht, 2011-10-19 11:31

31095_v2.patch (1.3 kB) Reinhard Führicht, 2011-10-21 13:17

Associated revisions

Revision 53193
Added by Reinhard Führicht over 1 year ago

Parse conditions again after the interceptors were called (fixes #31095)

Revision 53193
Added by Reinhard Führicht over 1 year ago

Parse conditions again after the interceptors were called (fixes #31095)

Revision 53507
Added by Reinhard Führicht over 1 year ago

Follow-Up-Patch: Accessing intercepted values in Conditions (fixes #31095)

Revision 53507
Added by Reinhard Führicht over 1 year ago

Follow-Up-Patch: Accessing intercepted values in Conditions (fixes #31095)

History

#1
Updated by Reinhard Führicht over 1 year ago

  • File 31095.patch added
  • Status changed from New to Accepted
  • Assignee set to Reinhard Führicht
  • Target version set to Stable v1.0

Could you please test the attached patch? It changes the controller to parse the conditions again after the interceptors have been called.

#2
Updated by Rainer Becker over 1 year ago

This works and is a great help for the application I am building. Thank you for your support!
Update: In the second/new condition check I change the validators. The required-marks appear accordingly but I can submit this step without filling the required fields.

#3
Updated by Reinhard Führicht over 1 year ago

  • Status changed from Accepted to Resolved
  • % Done changed from 0 to 100

Applied in changeset r53193.

#4
Updated by Rainer Becker over 1 year ago

Just want to be sure that you’ve read my last annotation - the validation added within the second condition check doesn’t work.

#5
Updated by Reinhard Führicht over 1 year ago

  • Status changed from Resolved to Accepted

It seems I didn't get an email notifying me about your comment.

I will investigate the problem you describe.

#6
Updated by Reinhard Führicht over 1 year ago

  • File 31095_v2.patch added
  • Status changed from Accepted to Needs Feedback
  • % Done changed from 100 to 80

I was able to reproduce what you describe.
Please test the attached additional patch.

The patch makes sure that after the conditions were parsed, the settings are merged with the step specific settings again.

#7
Updated by Reinhard Führicht over 1 year ago

Any news on this?

#8
Updated by Rainer Becker over 1 year ago

The changed validations are now handled correctly - thanks a lot!!

#9
Updated by Reinhard Führicht over 1 year ago

  • Status changed from Needs Feedback to Resolved
  • % Done changed from 80 to 100

Applied in changeset r53507.

#10
Updated by Reinhard Führicht over 1 year ago

Just out of curiosity, may I ask what your application does?
It sounds interesting that you wrote interceptors to "calculate" values.

#11
Updated by Rainer Becker over 1 year ago

I created three slightly different order forms. The user can check some products (the checkboxes are generated through product records) and for every product there are different kinds of licenses with variable costs for every product. When the user updates his form numerous different prices have to be calculated. For the calculation the modular architecture of formhandler was really great. So my setup consists of:
  • some product records containing name and different prices
  • some TS constants (for base prices and links)
  • three form templates
  • roundabout 1400 lines of TS setup for multiple form steps and dynamic validation
  • one php interceptor class for each form type to calculate submitted values and save them to gp-array
  • master template with every input field type and output field for html and plaintext
  • a template file for field combos (input and output) like personal data which are the same in all forms
  • and - the best - an highly reactive extension developer - that’s you :-)

#12
Updated by Reinhard Führicht over 1 year ago

Wow, that sounds like a lot of work! Thanks for the explanation.
I think, I never built such a complex form myself using Formhandler.
I am very happy that this worked without any mayor problems. It seems that I did at least some things right when thinking about the extension's architecture. :-)

#13
Updated by Reinhard Führicht over 1 year ago

Another question came up, sorry for nagging. :-)

We are currently preparing a website dedicated to Formhandler and its documentation and we would like to gather and present some user feedback on the website. Would it be OK for you, if we published this information on the website? (The domain is typo3-formhandler.com and it should be online within the next week)

#14
Updated by Rainer Becker over 1 year ago

You’re welcome!

#15
Updated by Reinhard Führicht over 1 year ago

Thanks!

Also available in: Atom PDF