I am trying to find out what is the best approach for my task:
Create a form with validation, spamcheck etc. using existing functionality. The results of the form must be handled in an extension and sent to an external application via REST api. Additionally, an email should be sent.
I am still struggling with TYPO3 and would like some help for what might be a good approach. I would like to use existing functionality as much as possible and not reinvent the wheel.
there is the ext:form framework. I saw that there are finishers, but not that it might be possible to send the results of the form to a Controller action
if that is not possible, is it possible for my extension to get notified (e.g. signal / slot) when a form has been submitted
alternatively, I could use Fluid form ViewHelpers. I did not find much information about how to handle the validation
form.validationResults : I don't exactly understand what it does.
handle validation via JavaScript
Any pointers are appreciated.
Related
I was browsing the typo3 core Forms framework documentation but with no relevant answer to my requirements which are:
The form has to be displayed in a frontend overlay.
The filling process involves multiple steps where the user would be able to go back and forth.
The form fields must still be editable by a redactor.
I'm not sure about how the form framework behaves, so far I remember I think that multiple steps are configurable from the backend module but I don't know if it sends request to the controller after each step or if it sends everything only on submit.
I have an idea about how to implement it though, it's based on this question how to get a typo3 form framework html via ajax. Which would just let me provide the whole html content to the frontender and let him split the whole form into steps. The separation would be based on the addition of some special tags via the editor that would surround the fields you want in each step.
What do you think about that approach?
The form framework proceeds each form step seperately. So without developing your own form runtime, you have to keep proceeding every step seperate.
I see two possibilities:
1. Send each form step from frontend to the form controller and replace the response (html form) in the frontend.
That is the fast and easy way, as you use the existing form runtime.
Prepare a page which returns the rendered form as html
Fetch this page by JavaScript
Send the form data back to the given form action
The form controller proceeds the form with all its validators, rules and finishers and returns the next step, previous step, the current step with existing errors or the finishers response on success
Replace your form in the frontend with the already rendered html response of the form framework
The advantage of this way: Less effort and you can rely on the already existing validators, as you get an already validated response.
The disadvantage of this way --> it is more difficult to implement frontend validation, as you have a mix between frontend and server side validation.
2. Make the form framework kind of headless and work json based
In my opinion the better approach, but with a lot more effort to take.
You have to extend / overwrite the controller and the form runtime. This allows you more flexibility in handling the form by JavaScript and e.g. return the errors in a json object. It makes life easier when you want the form render and handle with a JS framework like react or vue.
To your question:
What do you think about that approach?
If I got it right, you want to keep ONE form step in the backend, but let the editor divide this form step into multiple steps by adding tags? You can try, but I don't see any real advantage in keeping the original form steps and proceed every step by sending the step to the controller and handle the response (like mentioned in 1.)
Summary:
In the past, I was thinking a lot about handling forms by JavaScript and came to the conclusion:
Keep the form framework's behaviour completely untouched with server side processing or make it frontend driven, with an own runtime. All mixtures between client and server side rendering will sooner or later run into bigger problems or at least a high effort. The form framework is pretty complex with a lot of possibilities, hook driven behaviour, etc. From my experience, you have to know it pretty good to develop without loosing control. In smaller projects with just one or two basic forms, I would try to avoid special cases with lots of JS. In bigger projects (with more budget), I would definitely go with my second mentioned approach (currently, I'm developing vue.js based rendering and handling of the form frontend). But these are just my five cents...
Alright, so a better title here may have been "Progressive Enhancement with REST in CakePHP", but at least now I'll know you didn't read the question if your answer just refers to the difference between the two ;)
I'm pretty familiar with REST and how to integrate it with CakePHP, but I'm not 100% on board with how to still maintain a conventionally functioning website. Using Router::mapResources sounds like a great idea, but this creates a problem with maintaining the "gracefully degradation" version of the site, because both POST requests to /resource/ AND GET requests for /resource/add will route to the same action (add). Clearly I'll want this action to return a JSON object if they're using the REST api, but if they're using the degraded version of the site (no JS perhaps), it should be a add form, right?
What's the best way to deal with this. Do you route your REST requests to other action names using Router::resourceMap()? Do you do that crazy hack I saw to have the /api/ prefix part of the resourceMap so you can use api_action functions? Do you have the actions handle both REST and conventional requests via checking isAjax()? If so, how do you ensure that you can rely on the browser to properly support the other two request types?
I've searched around quite a bit but haven't found anything about how to keep conventional requests available in Cake along side REST, so if anyone has any advice or experience, I'd love to hear it!
CakePHP uses extension routing as well, via Router::parseExtension() so;
/test/action will render views/test/action.ctp
/test/action.html also
/test/action.json will render views/test/json/action.ctp
/test/action.xml will render views/test/xml/action.ctp
If all views are designed to handle the same data as set by your controller, you'll be able to show a regular HTML form and handle the posted data the same way as you'd handle the AJAX request.
You'll probably might have to add checks if any data is posted/submitted inside the /add, /edit, /delete actions to prevent items being deleted without a form being posted (haven't tested that though, it might be that cake blocks these urls if mapresources is set for the controller)
REST in CakePHP:
http://book.cakephp.org/2.0/en/development/rest.html
(Extension) Routing
http://book.cakephp.org/2.0/en/development/routing.html#file-extensions
I am working on a restaurant web portal which will send periodic emails to the registered users such as changes in menu, discounts and offers, birthday wishes etc.
Here is how I am doing it-
I create a JSP page with the HTML formatting. This page accepts certain parameters that will customize the page.
The MailDaemon scans the db and upon a certain trigger will make a GET request to the JSP.
The returned JSP represents the final mail content which is then sent using the JavaMail API.
My questions are these -
Do I really need to make a GET request? Or can I obtain the JSP result directly in my Daemon class?
Does my approach have any drawbacks? Any better solutions (architecturally speaking)
Any other templating solutions for the job?
It's possible to buffer a response from your JSP using javax.servlet.RequestDispatcher#include by wrapping original response in javax.servlet.ServletResponseWrapper (in case your MailDaemon is a servlet)
Your approach is OK. Though it'll be easier to leverage another templating engine.
Apache Velocity or FreeMarker. These two are not tied to web, so you can easily use them without servlet container.
If I understand correctly, you're using the JSP as a templating engine to generate the body of an HTML email. If you want to keep using JSPs for that, I don't think there's a better solution than making a GET request to get the generated HTML.
But you could also use an embeddable templating engine like Velocity or FreeMarker to generate the HTML to a String, directly from the mail daemon.
I have an idea to add a edit-layer to website as a Plack middleware.
Explanation: let's say, we create a website, based on some framework and templates and CSS (requesting it like /some/page). Now we could create a middleware so that every request to pages starting with adm (like /adm/some/page) shows the same page, but adds a layer for content editing. So we could easily look and use the page as visitors do, but with double-click on block-level element we could modify or add content. So middleware should bind certain block-elements with certain events (double-click) and set handlers too (with some Javascript library).
For now it is just an idea and i have not seen such approach in any CMS. I am looking for hints and ideas and examples, how to start and implement such system. I hope, there is already done something like that.
You could do it, but I don't think you want to do this. My understanding is that Plack::Middleware's are supposed to be generic, and implementing a CMS as a plack middleware limits its re-usability, and its out of place, there is no inherent connection between a middleware and a CMS.
See these as examples Plack::Middleware::OAuth, Plack::Middleware::Debug, Plack::Middleware::iPhone, Plack::Middleware::Image::Scale, Plack::Middleware::HTMLMinify
It would be trivial to add a middleware filter to insert a form in your html based on /adm/ or /admin/ or whatever ... and mapping the url to the dispatch would highly depend on the underlying CMS model/view/controller framework, which is why frameworks such as Catalyst, Mojolicious and other already provide this feature
See http://advent.plackperl.org/2009/12/day-23-write-your-own-middleware.html
Basically, I think this is a job for a view/controller of your application, a plugin, not a wrapper for your application (middleware)
I know my explanation is lacking but hopefully you catch my drift
I'm finding it hard to find out helpful information about ASP.NET MVC's validation HTML helpers - Html.Validate and Html.ValidateFor.
Has anyone worked with these methods? what are they for?
see this post for an answer
If there are situations where you
don't actually want a validation
message to visually appear for each
field (i.e. by using
Html.ValidationMessage), but would
rather allow a summary to be the sole
source of validation error messages
(i.e. by using
Html.ValidationSummary), you still
need some way to "trigger" the
validation to occur for the specific
fields you want it to.
This can be achieved by using the
Html.Validate/Html.ValidateFor<>
methods within your view. Those
helpers won't render anything, but
will simply register the specified
field for client-side validation.