I have an Extbase extension starting some background activities. To monitor the overall progress, there is a view displaying current state. How can this view be reloaded, say every 10-15 seconds? The best thing was to reload only this part of the page.
Use AJAX. To get the result of a specific action instead of the whole page, you can use the extension typoscript_rendering - it's made for this exact purpose.
To use it, you need to do something along these lines:
Create a controller action that renders the output you want to use for reloading.
In the fluid template where you want to reload the output, render the URL to use for rendering that output using the ViewHelper helhum:uri.ajaxAction from the above-mentioned extension. Put it into some data-attribute or something.
Fetch the content at that URL using AJAX - if you need adapt parameters for each call, it's probably best to do POST requests. You need to implement this manually - TYPO3 does not come with prebuilt JS for this.
Related
I have a form within a tab. It is second tab so it doesn't render until you open it.
I have tried to submit data to the form with Ext.getCmp('DetailsForm').getForm().setValues(selections[0]); but it says that it is not a function. Probably because it is not rendered yet. What I have to do?
Set the deferredRender config property of your Ext.tab.Panel to deferredRender: false
That will force the rendering of all tabs instead of just active ones. Now the form will be there. As mentioned before I recommend you also to use myTabPanelRef.down('from').getForm().setValues(selections[0]); to access the form.
subscribe to the second tabs show event OR painted event
then look for the form preferably by using .down() method as this wont look with in the entire DOM.
set the values
Use render event of form panel.
Your code will be something like this -
Ext.getCmp('DetailsForm').on('render', function(){
this.getForm().load(selections[0]);
});
Using Woodwing, we have a page that has custom html in it, using the custom web widget.
That widget has an anchor tag, that when tapped, opens a page in safari.
However, if we create the same page using the HTML widget, and a link overlay, that triggers a ModalView to display.
I'm assuming this has something to do with WoodWing's (un)documented protocols for the anchor tags, that are captured by the WoodWing shell application and used to trigger the "ModalView" display. Since everything in Woodwing generates an XML that is parsed when the app is loaded, and I've done numerous applications, this seems reasonable. However, there is very little technical documentation.
My question is: does anyone know any documentation on those protocols, or a way I can use custom-html to trigger the ModalView? I've tried replacing "http" with "ww" but no dice. It's possible it's javascript but I'm suspecting protocols...
The UIWebViewDelegate defines the webView:shouldStartLoadWithRequest:navigationType: method that your view controller can implement. In this implementation, your code shoudl decide if it wants to handle the request (user click) or let the UIWebView handle it normally.
For displaying a modal as a result of a click, this method would display the modal and return NO.
The default HTML widget implementation doesn't support this out of the box. There are two ways that you can do to achieve this;
Implement what they call a 'custom object'. They documented this feature, if you have access to their documentation this should be relatively easy to figure out. It allows you to write native objects and inject them into both the .ofip format and the application.
Implement a modal dialog within the widget (in HTML). This is less convenient but possible to do (if you have a fullscreen widget).
Create the specific URL for open as you mention in your comment(ww://string.string).
Then in UIWebView Delegate method (webView: shouldStartLoadWithRequest: navigationType:) get the redirect URL. If redirect URL is equal to you mention before then perform your action.
Let me know if this answer help you.
Thanks,
I would like to know what is the best method to have an action return different views. Let's say you have a form for submitting data, but you want to choose the view depending on what data is submitted. I would prefer not using a redirection, since there is stuff I want to be displayed in the data that is posted.
An example of this would be to have an Edit form that displays a Details view when clicking on Save, but without using a redirection.
I know this could be done with a single view containing a conditional if statement to display this or that, but there are cases where I would prefer my views to stay simple without too much code in them. If the controller could just choose the view to display once the data is posted, this would be great.
There is an overload to the View() method that allows you to specify the name of the View you want to return.
return View("DetailsView", model);
You should be using the Post/Redirect/Get pattern. You can still "display stuff." You can pass an ID on the URI and look them up in the new GET or use TempData.
Attempting to circumvent Post/Redirect/Get is not a good solution. Among other things, it breaks the back button.
I`m using asp.net mvc 2.0 and trying to create reusable web site parts, that can be added at any page dynamically.
The problem I have is how to load a partial view with all related js and data? Ive tried the following ways to do that:
Use partial view and put all the js into it. In main view use render partial. But to initialize partial view I need to add model to current action method model to be able to make RenderPartial("MyPartialView", Model.PartialViewModel).
Also I do not have a place to put additional data I need to fill my form(like drop down lists values, some predefined values etc).
Use RenderAction, but it seems it have same problems as RenderPartial, except for I do not need to add anything to any other model.
Any other oprions are greatly appreciated.
As I understand it, RenderAction performs the full pipeline on the action, then renders the result - so what is rendered is the same as what you'd see if you'd browsed to the action.
I've used RenderAction to render 'widgets' throughout a site, but in my view they should be independent of the page rendering them, otherwise they're not really widgets and should be part of the rendering page's code instead. For instance, if there's a log in form, you will always take the user to a page that can process the information, no matter what page they are currently on, so this makes for a good widget. Other ways I've used it is to show a shopping basket or advertising. Neither of which are dependent on the page being shown.
Hope this helps a little!
I've been working with Zend Framework (using Doctrine as the ORM) for quite a while now, and done a few projects with it.
In a few upcoming projects I am requiring the need for widgets similar to how Wordpress does them. You have a post/page, which could look like:
Subscribe to my newsletter:
[subscribe/]
View my events
[events limit=5 sort=date/]
View this page's comments
[comments/]
Where say the subscribe widget would be replaced with Blog::subscribeWidget, and the events could be replaced with Events::eventsWidget, etc.
Now it has done my head in the past few weeks about how on earth do I do this??? I've come up with the following options:
I could place the widgets within controllers, and then call them like actions. Problem here is that code could be flying between controllers, and I have read this is expensive due to the amount of dispatches.
I could place the widgets as view helpers. So within the view I could have $this->renderPage($Page), which would then attend to all the widgets. Problem here is that what if the widgets need to do some business logic, like for example posting a new comment, that really shouldn't be within the view, should it?
The other option is to place widgets within the model? But then how on earth do they then render content for display?
Extra complications come when:
Say the comments widget would also handle posting, deleting of comments etc.
Say for the events listing, if I want to do an ajax request to the next page of events, using method #2 (view helpers) how would this work?
If I understand you correctly your widgets will need their own action controllers, which is where their logic for fetching data to be displayed, parsing form submissions, etc. should go. The difference between a widget and a page in this case is in how it's rendered, i.e. as an HTML fragment instead of as a whole page; you can use the Action View Helper to achieve this.
If your widget includes a form it should probably use AJAX to submit the form data back to the server, so that using the widget doesn't cause the user to accidentally navigate away from the page. You can inject the required JavaScript into the page you've included the widget into by using the Head Script Helper in your widget's view and/or action.
I left Richards reply, the problem, and further use cases cook in my brain for a while longer and ended up coming to a solution.
I will have the following view helpers and methods:
Content; with methods: render, renderWidgets, renderWidget, renderCommentsWidget (comments).
Event; with methods: renderEventsWidget (many events), renderEventWidget (one event)
Subscription; with methods: renderSubscribeWidget (subscription form).
I will have inside my configuration file:
app.widgets.comments.helper = content
app.widgets.subscribe.helper = subscription
app.widgets.events.helper = event
I will also have the following models:
Content for use for all pages.
Event for use for all events.
Subcriber for use for subscriptions to content
So inside my view I will do something like this:
echo $this->content()->render($this->Content)
Content::render() will then perform any content rendering and then perform rendering of the widgets by passing along to Content::renderWidgets(). Here we will use the configuration of app.widgets to link together the widget bbcode tag to it's appropriate view helper (using the naming convention 'render'.ucfirst($tag).'Widget'). So for example Content::renderCommentsWidget() would then proceed to render the comments.
Perhaps later on I will decide to have a Widget View Helper, and individual view helpers for each widget eg. ContentCommentsWidget View Helper. But for now that would just add additional unrequired complexity.
Now to answer the AJAX problem I mentioned. Say for the comments widget allowing for comments to be posted via ajax. It would simply have an appropriate method inside the Content Controller for it. So pretty much we also have a Event and Subscription controllers too - corresponding with the view helpers. Interaction between the view helper and controller will all be hard coded, there is no purpose for it to be soft coded.
I hope this helps someone else, and the current plan is to make the project where all this is used to be an open-source project. So maybe one day you can see it all in action.
Thanks.
Update:
You can find the source code of these ideas in action in the following repositories:
BalCMS - this is the actual CMS which contains the widgets in /application/modules/balcms/view/helpers and contains the configuration in /application/modules/config/application/balcms.yaml
BalPHP - this is the resource library which contains the widget view helper at /lib/Bal/View/Helper/Widget.php