As our page numbers grow I'm starting to run into difficulties preventing duplicate frames, especially when using the side drawer. If I navigate A -> B -> A, I will end up with 3 instances, 2 of A and 1 of B. This means I have to somehow decided whether the navigation is a real navigation or a "backToPreviousPage".
Ideally I should just be able to put a route in and it would intelligently decide what to do, e.g:
router.navigate(['A'])
router.navigate(['B'])
router.navigate(['A'])
Should equal A - navigate -> B - backToPreviousPage -> A
Right now, my plan is to make a service to record the last route that was navigated to. That way I can just do myService.navigate() and it will automatically decide if it should do a real navigation or use routerExtensions.backToPreviousPage() based on if the current route matches the previous.
Before I do that though, I want to make sure there isn't some glaring obvious way I should be handling this. This kind of seems like a dirty way to do it. To me it seems like the Nativescript router should handle this by default, but I've already confirmed that my A -> B -> A scenario re-runs the ngOnInit, and I haven't seen any options that could make this happen.
The page router outlet should keep track of what is there in stack / history. Based on url segments you could decide whether you want to navigate back or navigate to new component.
constructor(pageRouterOutlet: PageRouterOutlet) {
// `outlet` is private
(<any>pageRouterOutlet).outlet.states.forEach((state) => {
console.log(state.segmentGroup);
});
}
Related
It may sound like a pedantic question. Sorry :)
I have a case like this... here's my router definition:
Router.map(function() {
this.resource('gobernadores', { path: '/gobernadores' }, function() {
this.resource('gobernador', { path: '/:id_estado' }, function() {
this.route('simulacion', { path: '/simulacion' }),
this.route('info', { path: '/info' })
})
});
this.route("login");
this.route("bienvenido");
});
In the "gobernadores" route, I have list of provinces. You can see it's a nested layout. In that same page, we're showing the currently-selected province (that's the gobernador route). Inside the template for that gobernador route, I have a tab, with two elements..., one showing the route "simulacion", and the other one showing the template of route "info" (of that province).
Now, the problem: as user jumps from one province to another province (by clicking the navigation menu on the left side of the screen), I want to keep in memory, the tab that was currently selected, for each province.
So, if the user is currently seeing the result of simulacion of province X, and then he clicks on the link to go to province Y (where he will be presented with "info" of province Y), and then he goes back to province X, I want the app to take the user back to the screen he was seeing (the simulacion of province X).
You can't have that information stored in the controller (GobernadorController), because I can see that controllers can't keep state, it's stateless.
So..., I have to move that info into the model of the route (GobernadorRouteModel)...
My doubt: is it okay? Why my doubt? Because of this: http://emberjs.com/guides/concepts/core-concepts/
It says:
MODELS
A model is an object that stores persistent state. Templates are
responsible for displaying the model to the user by turning it into
HTML. In many applications, models are loaded via an HTTP JSON API,
although Ember is agnostic to the backend that you choose.
ROUTE
A route is an object that tells the template which model it should
display.
This GobernadorRouteModel is not something I persists in the backend. I have no intention to do that. So, am I violating the general advice for a good EmberJS app?
Or in other words: "persistent" here doesn't have to mean "something you save into DB", right? It's just "something you want to keep around..., eventhough only during the session of the app, in the memory".
Thanks in advance,
Raka
You can't have that information stored in the controller (GobernadorController), because I can see that controllers can't keep state, it's stateless.
This might be where your problem arises. Controllers are not stateless. Controllers in Ember are singletons and keep their state throughout the lifecycle of the app. However, this is going to change in Ember 2.0. To quote from that RFC:
Persistent state should be stored in route objects and passed as initial properties to routable components.
So if you're trying to be forward-compatible, that is the approach I would take. In my opinion, models should really only be used for persistent state (persistent meaning it's persisted between page loads). To keep session state, I would do as the RFC says and keep that state in the routes and inject it into the controllers during the resetController hook.
Or if you don't want to be that fancy and you don't care about forward-compatibility, just have a global Session object that you store state in. That's how I currently do it and it works quite well. (Although we will probably move away from it.)
TL;DR: No, I don't think you're using models for their intended purpose.
So I’m looking to make some routes within my super cool can.js application. Aiming for something like this…
#!claims ClaimsController - lists claims
#!claims/:id ClaimController - views a single claim
#!claims/new ClaimController - creates a new claim
#!claims/:id/pdf - do nothing, the ClaimController will handle it
#!admin AdminController - loads my Administrative panel with menu
#!admin/users - do nothing, the AdminController will handle it
#!admin/settings - do nothing, the AdminController will handle it
So how might we do this?
“claims route”: function() { load('ClaimsController'); },
“claims/:id route”: function() { load('ClaimController'); },
“admin”: function() { load(‘AdminController’); },
Cool beans, we’re off. So what if someone sends a link to someone like...
http://myapp#!claims/1/pdf
Nothing happens! Ok, well let’s add the route.
“claims/:id/pdf route”: function() { load('ClaimController'); },
Great. Now that link works. Here, the router’s job is only to load the controller. The controller will recognize that the pdf action is wanted, and show the correct view.
So pretend I’ve loaded up a claim claims/:id and I edit one or two things. Then I click the Print Preview button to view the PDF and change my route to claims/:id/pdf.
What should happen… the Claim Controller is watching the route and shows the pdf view.
What actually happens… the router sees the change, matches the claims/:id/pdf route we added, and reloads the Claim Controller, displaying a fresh version of the claim pulled from the server/cache, losing my changes.
To try and define the problem, I need the router to identify when the route changes, what controller the route belongs to, and if the controller is already loaded, ignore it. But this is hard!
claims //
claims/:id // different controllers!
claims/:id //
claims/:id/pdf // same controller!
We could just bind on the "controller" change. So defining routes like can.route(':controller') and binding on :controller.
{can.route} controller
// or
can.route.bind('controller', function() {...})
But clicking on a claim (changing from ClaimsController to ClaimController) won't trigger, as the first token claim is the same in both cases.
Is there a convention I can lean on? Should I be specifying every single route in the app and checking if the controller is loaded? Are my preferred route urls just not working?
The following is how I setup routing in complex CanJS applications. You can see an example of this here.
First, do not use can.Control routes. It's an anti-pattern and will be removed in 3.0 for something like the ideas in this issue.
Instead you setup a routing app module that imports and sets up modules by convention similar to this which is used here.
I will explain how to setup a routing app module in a moment. But first, it's important to understand how can.route is different from how you are probably used to thinking of routing. Its difference makes it difficult to understand at first, but once you get it; you'll hopefully see how powerful and perfect it is for client-side routing.
Instead of thinking of urls, think of can.route's data. What is in can.route.attr(). For example, your URLs seem to have data like:
page - the primary area someone is dealing with
subpage - an optional secondary area within the page
id - the id of a type
For example, admin/users might want can.route.attr() to return:
{page: "admin", subpage: "users"}
And, claims/5 might translate into:
{page: "claims", id: "5"}
When I start building an application, I only use urls that look like #!page=admin&subpage=users and ignore the pretty routing until later. I build an application around state first and foremost.
Once I have the mental picture of the can.route.attr() data that encapsulates my application's state, I build a routing app module that listens to changes in can.route and sets up the right controls or components. Yours might look like:
can.route.bind("change", throttle(function(){
if( can.route.attr("page") == "admin" ) {
load("AdminController")
} else if(can.route.attr("page") === "claims" && can.route.attr("id") {
load("ClaimController")
} else if ( ... ) {
...
} else {
// by convention, load a controller for whatever page is
load(can.capitalize(can.route.attr("page")+"Controller")
}
}) );
Finally, after setting all of that up, I make my pretty routes map to my expected can.route.attr() values:
can.route(":page"); // for #!claims, #!admin
can.route("claims/new", {page: "claims", subpage: "new"});
can.route("claims/:id", {page: "claims"});
can.route("admin/:subpage",{page: "admin"});
By doing it this way, you keep your routes independent of rest of the application. Everything simply listens to changes in can.route's attributes. All your routing rules are maintained in one place.
I have a module which allows the user to choose a category, which is then used for filtering the component's output. So when the user first clicks on the menu item, the view shows items from all categories, then as they click on the module, a param such as &catid=69 etc. is added to the url and used to filter the items displayed.
A system plugin complements the behaviour by registering the extra catid param i.e.
$registeredurlparams->catid = 'INT';
$app->set('registeredurlparams', $registeredurlparams);
The module uses the category id to create the cache id, and shows the top-level categories + the subcategories of the category that was chosen.
This works fine with both conservative cache enabled in the system configuration and the System Cache plugin enabled.
My concern is that I cannot get it to work with progressive cache: even though the component output is cached correctly, the module doesn't get updated (so I never see the subcategories).
Eventually I plan to make the extension available on the JED, and I'd like to be compatible with all possible cache configurations. Is there any possibility to force the progressive cache to add the parameters I want to the cache id?
Workarounds such as sending the full category tree and doing it with ajax will not be accepted.
One thing you could look at is ContentModelArticle in the back end. You will notice that cleanCache()
forcibly clears the content modules that could be impacted by a save or create.
protected function cleanCache($group = null, $client_id = 0)
{
parent::cleanCache('com_content');
parent::cleanCache('mod_articles_archive');
parent::cleanCache('mod_articles_categories');
parent::cleanCache('mod_articles_category');
parent::cleanCache('mod_articles_latest');
parent::cleanCache('mod_articles_news');
parent::cleanCache('mod_articles_popular');
}
I've always thought this was a sledge hammer/kludge since it doesn't let the webmaster control whether or not to do this, but you could do something along the lines of making a custom cleanCache() for your model.
In Manage Customers tab, by default last 20 registered users are listed with their emails. I would like to hide the list or change it only 1. This is being done to make sure that call center agents are not easily copying customer's email information.
I am very new to this so, if its not too much trouble, provide full path to the file.
Steve
You might want to go a slightly different direction, by developing a set of permissions for your Agents, so that perhaps they can't access the email in the first place, if you don't want them to see that information.
If you want to modify the page size, you can rewrite this class
Mage_Adminhtml_Block_Customer_Grid
And you'll want to override this method:
protected function _preparePage()
{
parent::_preparePage();
$this->getCollection()->setPageSize(1);
}
You may also want to get rid of the pagination dropdown in
app/design/adminhtml/default/default/template/widget/grid.phtml
because it will be confusing for them to see it but when they use it for it to not function.
I develop the system where I assume will be many users. Each user has a profile represented inside the application as a record. To store user's profile I do the following base64:encode_to_string(term_to_binary(Profile)), so basically profiles stored in serialized maner.
So far everything is just fine. Now comes the question:
From time to time I do plan to extend profile functionality by adding and removing certain fields in it. My question is what is a best strategy to handle these changes in the code?
The approach I see at the moment is to do something like this:
Profile = get_profile(UserName),
case is_record(Profile, #profile1) of
true ->
% do stuff with Profile#profile1
ok;
_ ->
next
end,
case is_record(Profile, #profile2) of
true ->
% do stuff with Profile#profile2
ok;
_ ->
next
end,
I want to know if there are any better solutions for my task?
Additional info: I use is simple KV storage. It cannot store Erlang types this is why I use State#state.player#player.chips#chips.br
Perhaps, you could use proplists.
Assume, you have stored some user profile.
User = [{name,"John"},{surname,"Dow"}].
store_profile(User).
Then, after a couple of years you decided to extend user profile with user's age.
User = [{name,"John"},{surname,"Dow"},{age,23}].
store_profile(User).
Now you need to get a user profile from DB
get_val(Key,Profile) ->
V = lists:keyfind(Key,1,Profile),
case V of
{_,Val} -> Val;
_ -> undefined
end.
User = get_profile().
UserName = get_val(name,User).
UserAge = get_val(age,User).
If you get a user profile of 'version 2', you will get an actual age (23 in this particular case).
If you get a user profile of 'version 1' ('old' one), you will get 'undefined' as an age, - and then you can update the profile and store it with the new value, so it will be 'new version' entity.
So, no version conflict.
Probably, this is not the best way to do, but it might be a solution in some case.
It strongly depend of proportion of number of records, frequency of changes and acceptable outage. I would prefer upgrade of profiles to newest version first due maintainability. You also can make system which will upgrade on-fly as mnesia does. And finally there is possibility keep code for all versions which I would definitely not prefer. It is maintenance nightmare.
Anyway when is_record/2 is allowed in guards I would prefer
case Profile of
X when is_record(X, profile1) ->
% do stuff with Profile#profile1
ok;
X when is_record(X, profile2) ->
% do stuff with Profile#profile2
ok
end
Notice there is not catch all clause because what you would do with unknown record type? It is error so fail fast!
You have many other options e.g. hack like:
case element(1,Profile) of
profile1 ->
% do stuff with Profile#profile1
ok;
profile2 ->
% do stuff with Profile#profile2
ok
end
or something like
{_, F} = lists:keyfind({element(1,Profile), size(Profile)},
[{{profile1, record_info(size, profile1)}, fun foo:bar/1},
{{profile2, record_info(size, profile2)}, fun foo:baz/1}]),
F(Profile).
and many other possibilities.
The best approach is to have the copy of the serialized (profile) and also a copy of the same but in record form. Then , each time changes are made to the record-form profile, changes are also made to the serialized profile of the same user ATOMICALLY (within the same transaction!). The code that modifies the users record profile, should always recompute the new serialized form which, to you, is the external representation of the users record-record(record_prof,{name,age,sex}).
-record(myuser,{
username,
record_profile = #record_prof{},
serialized_profile
}).
change_profile(Username,age,NewValue)->
%% transaction starts here....
[MyUser] = mnesia:read({myuser,Username}),
Rec = MyUser#myuser.record_profile,
NewRec = Rec#record_prof{age = NewValue},
NewSerialised = serialise_profile(NewRec),
NewUser = MyUser#myuser{
record_profile = NewRec,
serialized_profile = NewSerialised
},
write_back(NewUser),
%% transaction ends here.....
ok.
So whatever the serialize function is doing, that's that. But this always leaves an overhead free profile change. We thereby keep the serialized profile as always the correct representation of the record profile at all times. When changes occur to the record profile, the serialized form must also be recomputed (transactional) so as to have integrity.
You could use some extensible data serialization format such as JSON or Google Protocol Buffers.
Both of these formats support adding new fields without breaking backwards compatibility. By using them you won't need to introduce explicit versioning to your serialized data structures.
Choosing between the two formats depends on your use case. For instance, using Protocol Buffers is more reliable, whereas JSON is easier to get started with.