In AngularJs I can do this:
<header data-ng-include="views/header.html"></header>
which AFAIK asynchronously downloads views/header.html from client and interprets it as a template.
I want to ask if there is any sane motivation to use it because all I encountered with this was a pretty bad usex experience. I have a black Twitter Bootstrap header and this causes the header to show a moment later and therefore "hits" the user right in the eyes once all other content is visible.
On the top of that it does the request every time eventhough it just for a 304.
You can use an ng-include to separate some HTML that is re-used, you can also bind the data-ng-include to a variable on your scope and change the view similar to what you get with ng-view and using the $routeProvider configuration.
I'm not entirely sure about the attempted reload and seeing the not modified response. I would assume ng-include would operate under the same caching rules as a normal page but perhaps something is different since it does an AJAX request for it I assume.
I think you should be able to make it sync loading by adding a public counter to the on-load property of ng-include. And you can then wait the counter to increment to be the number of the templates loaded by ng-include, and then after all templates are loaded continue with other logic.
There are definitely some advantages of using ng-include. For example, you can use it together with ng-switch to conditionally load a template. And it also automatically creates a child scope if you want to isolate model from the current scope.
Hope it can shed some light on.
Related
I have a long list that I want to let the user manipulate in a browser-based web application. Using jQuery, the most straightforward way would be to render it on the server as part of the initial page load, and include a small script that registers event handlers for AJAX requests and DOM manipulation.
In the case of VueJs however, it seems to me that the most straightforward way is for the initial request to load the page layout only, then call an API to get the data for the long list. In other words, VueJs renders the initial list, not the server.
While this is workable, I am hesitant to introduce this second request unless I really have to. Is there a more straightforward way to go about this? Am I missing something about how VueJS works? I would really like to render the initial list on the server side if possible. For example, would it be workable to somehow include the initial list as 'transcluded' content?
I don't want to have to get in to VueJS' complete server side rendering, since it looks like an advanced topic (and this is a simple task). I have experimented with passing the initial list data as JSON in the <head> of the page (inside tags that register it as a javascript variable), but that seems like a hack/workaround.
In the case of VueJs however, it seems to me that the most straightforward way is for the initial request to load the page layout only, then call an API to get the data for the long list. In other words, VueJs renders the initial list, not the server.
Yes, it is most straightforward way, and considered as anti-pattern also. Just for the reason in your next sentence: "While this is workable, I am hesitant to introduce this second request"...
I think you should read following post on medium.com first. It is about Vue and Laravel framework, but the principles herein can be considered universal:
https://medium.com/js-dojo/avoid-this-common-anti-pattern-in-full-stack-vue-laravel-apps-bd9f584a724f
I am running a Web Application with, among other things, PrimeFaces 3.2 on a Wildfly 10.1.x server.
The entire application uses Spring WebFlow with loads of SubFlows and inherited components and whatnot.
The normal behavior (which we have most of the time) is, that an Ajax-Request is sent to the Flow, which triggers an action, and then returns a partial response which should be rendered.
Sometimes though, when I click on a button, the action is triggered, but the response is entirely crippled - a few tags are opened, but none are closed, and there is effectively no content.
Basically, something like this:
<partial-response>
<changes>
<update id="j_idt77">
<![CDATA[
<script type="text/javascript">
which of course leads to errors when trying to render it. Sometimes, refreshing the page resolves the issue, but most of the time, it does not.
I was unable to reliably reproduce this behavior, the next best thing I could do was cause a NullPointerException in the backing Java-Code, which in turn led to a broken flow, but the corresponsing response was entirely valid and not mutilated at all.
The Server Log hat no error messages whatsoever. As I got this as a bug report, and am so far unable to reproduce it, I cannot post any more details about the error, I have seen it, so I know it happens, but I have no idea how.
EDIT
Updated Error message.
Plus, a little more info here:
the referenced id j_jdt77 was used over several reloads, recached reloads and different browsers.
The id is not referenced anywhere in the currently rendered document, or the document to be rendered.
I don't know if that helps or not, but I certainly find it interesting and important enough to add.
EDIT 2
A bit more information that could be gathered by now:
The component j_idt77 is a component, that should not be reloaded on a partial view. I can be sure of this as the partial re-rendering should only happen within a subform named adminForm, and on all successful calls, on every conceivable click-combination, all <partial-response> documents contained 3 - 4 ids for updating, one being messages for obvious reasons, the last being javax.faces.ViewState and the rest being id's of composure adminForm:XXX where XXX is the element to update.
j_idt77 is a component that should be loaded once, so I am entirely unsure if that is relevant or not. I was able to trigger a reload of a component outside of that scope, however the ID's are differend now, because I added a <ui:debug /> tag and changed the PROJECT_STAGE to Development. I am unsire how the id's are being generated right now, if my guess is correct (regular increment, basically the numbers are updated by a value of X with the extra settings) the element WOULD be a javascript resource.
Concerning updating: I was told that we could look into an update if it is guaranteed to fix this behavior, so basically, I'd still need to know what exactly goes wrong here.
I have a fairly complex app, with lots of different components that update frequently. For example, a clock.
Is it possible to call $apply / $digest on only a subsection of the page at once? I don't want to call every watcher on the page for every single clock tick, for example.
I know I can achieve this by bypassing $scope.$apply entirely, and just updating the clock elements manually in a directive. Is there any hope for me?
EDIT: Actually, it looks like MAYBE what I want is to dun $digest, starting on the scope I want to check, rather than $apply, since $apply kicks off the digest on $rootScope. Is this a valid way to do it?
http://plnkr.co/edit/C8aOswf46qx2GoD5uL9Y?p=preview
If your components are really decoupled, you could isolate those that generate frequent updates in their own angular app instance. They will have independent digest cycles.
Your apps can still communicate but there is a bit more overhead involved.
In order to have 2 apps, you have to manually start the applications (use bootstrap instead of ng-app).
See this example: http://plnkr.co/edit/K3bnACFi79g5Kh0kFS66?p=preview
Whenever you call $scope.$apply() it also calls $apply() on all scopes that fall within that scope. If you want to call $apply() on a limited section of a page then that section needs to have it's own scope, which you can do by adding a controller to that section of the page. Then you can use that controller to update the scopes within that section of the page using $scope.apply() on your section controller.
-- Edit --
See comments below for additional details about the differences between $apply and $digest.
Also see:
http://jimhoskins.com/2012/12/17/angularjs-and-apply.html
https://groups.google.com/forum/#!topic/angular/SSj61VOBBSc
I have a very large webform that is the center of my Yii web application. The form actually consists of multiple html form elements, many of which are loaded via AJAX as needed.
Because of the form's size and complexity, having multiple save or submit buttons isn't really feasible. I would rather update each field in the database as it is edited by asynchrously AJAXing the new value to the server using jeditable or jeditable-like functionality.
Has anyone done anything like this? In theory I'm thinking I could set up an AJAX endpoint and have each control pass in its name, its new value, and the CRUD operation you want to perform. Then the endpoint can route the request appropriately based on some kind of map and return the product. It just seems like someone has to have solved this problem before and I don't want to waste hours reinventing the wheel.
Your thoughts on architecture/implementation are appreciated, thanks for your time.
In similar situation I decided to use CActiveForm only for easy validation by Yii standarts (it can use Ajax validation), avoiding "required" attribute. And of course to keep logical structure of the form in a good view.
In common you're right. I manually used jQuery to generate AJAX-request (and any other actions) to the controller and process them there as you want.
So you may use CRUD in controller (analyzing parameters in requests) and in your custom jQuery (using group selectors), but you can hardly do it in CActiveForm directly (and it's good: compacting mustn't always beat the logic and structure of models).
Any composite solution with javascript in PHP will affect on flexibility of your non-trivial application.
After sleeping on it last night, I found this post:
jQuery focus/blur on form, not individual inputs
I'm using a modified version of this at the client to update each form via AJAX, instead of updating each field. Each form automatically submits its data after a two seconds of inactivity. The downside is the client might lose some data if their browser crashes, but the benefit is I can mostly use Yii's built-in controller actions and I don't have to write a lot of custom PHP. Since my forms are small, but there are many of them, it seems to be working well so far.
Thanks Alexander for your excellent input and thanks Afnan for your help :)
When a screen has multiple interacting Ajax controls and you want to control the visibility of components to react to these controls (so that you only display what makes sense in any given situation), calling target.addComponent() manually on everything you want to update is getting cumbersome and isn't very maintainable.
Eventually the web of onClick and onUpdate callbacks can reach a point where adding a new component to the screen is getting much harder than it's supposed to be.
What are the commonly used strategies (or even libraries if such a thing exists) to avoid this build-up of complexity?
Update: Thank you for your answers, I found all of them very useful, but I can only accept one. Sorry.
In Wicket 1.5 there is an event bus. Each component has onEvent(Object payload) method. With component.send() you can broadcast events and each component can check the payload (e.g. UserJoinedEvent object) and decide whether it wants to participate in the current Ajax response. See http://www.wicket-library.com/wicket-examples/events/ for a simple demo.
You could add structural components such as WebMarkupContainers, when you add this to the AjaxTarget everything contained in it will also get updated. This allows you to update groups of components in a single line.
When I'm creating components for a page I tend to add them to component arrays:
Component[] pageComponents = {
new TextField<String>("Field1"),
new TextField<String>("Field2"),
new TextField<String>("Field3")
}
As of Wicket 1.5 the add functions take array parameters [1]. Therefore elements can be added to the page or target like this:
add(pageComponents);
target.add(pageComponents);
Components can then be grouped based on which you want to refresh together.
[1] http://www.jarvana.com/jarvana/view/org/apache/wicket/wicket/1.5-M3/wicket-1.5-M3-javadoc.jar!/org/apache/wicket/ajax/AjaxRequestTarget.html
Well, of how many components do we speak here? Ten? Twenty? Hundreds?
For up to twenty or about this you can have a state controller which controls which components should be shown. This controller sets the visible field of a components model and you do always add all components to your requests which are handled by the controller. The components ajax events you simply redirect to the controller handle method.
For really large numbers of components which have a too heavy payload for a good performance you could use javascript libraries like jQuery to do the show and hide things by the client.
I currently use some sort of modified Observer-Pattern to simulate an event-bus in Wicket 1.4.
My Pages act as an observable observer since my components don't know each other and are reused in different combinations across multiple pages. Whenever one component receives an Ajax-event that could affect other components as well, it calls a method on it's page with an event-object and the ajax-target. The page calls a similar method on all components which have registered themselves for this kind of event and each component can decide, on the base of the supplied event-object if and how it has to react and can attach itself to the target.
The same can be archived by using the wicket visitor. I don't know which one is better, but I think that's mainly a matter of taste.