After reading Marionette.Commands I am very curious to finding difference between normal functions and Marionette.Commands.
If you define any function, you can call that function wherever you want.
normal Function :
var normalFun=function(){alert("Normal Function")};
same way Marionette.commands also working like in the following way.
//creating instance for Application class
var myApp=new Marionette.Application();
//registering command
myApp.Commands.setHandler("functionName",function(){alert("This is just a normal function but way of defining as different in my point of view.")});
//whereever you want to call this command just run that command with corresponding name
myApp.Commands.execute("functionName");
What I am thinking, both normal functions and Marionette.Commands are same. If it is right then why did Marionette developers develop this Marionette.Commands concept?
To use a function, you need to either call it from the same scope, or have a reference to a containing object. This isn't the case for commands, so they allow for decoupling.
Say you want to change the color of the menu when a user clicks on some button in your app. You can define a changeColor function in (e.g.) the portion of your application that manages the header. Then, you can make the menu color change by calling (e.g.) myHeader.changeColor() from somewhere in your application. But as mentioned above, that means you need a reference to myHeader to be able to call its changeColor method.
As you develop your application, you realize that actually the menu itself is getting quite complex, and it makes more sense for it to change its own color directly (instead of having the header manage the color). Now you need to go in your application and change every instance of myHeader.changeColor() to myMenu.changeColor(). This is due to the coupling of the various bits of your application.
If instead you use commands, you would execute the command from the places that need to change the menu color, and you'd define the handler in the "header" part. Then when you decide to change your application design, you can simply move the handler so it's defined in the "menu" part. With this solution, you won't have to change the actual calls to change the menu color, because they're entirely decoupled.
With both solutions, you can change the menu color. But using commands allows for better decoupling and less work down the road. Of course, this doesn't mean you should use commands everywhere: adapt their use (or not) to your particular case.
They are the same. I mean everything is the same down the road (a function), always. Haha.
What's important is what you make out of it. So, in the end, it is just a matter of taste/professionalism (respecting patterns, conventions, etc..).
With the commands, you have everything in one place and only myApp is responsible for communicating between the modules/the controllers/the domains/whatever "functional end result" (to quote #David Sulc very good book: "Backbone.Marionette.js: A Gentle Introduction") of your application.
So long story short: In a big app, it makes sense to only pass around the myApp instance, and executes the commands from there.
Note: And that makes even more sense when you're using RequireJS.
That's cleaner, more structured.
Related
I was working on an HTML block in Concrete5 located in the footer. I made a javascript call - can't quite remember it, but I think it was referencing either jQuery or the Google Maps API. Anyway, now the block won't display and oddly enough, I am completely unable to modify/add/remove blocks now. I'm pretty sure it is because of the javascript call it is making, but I can't modify or delete the block to fix the issue.
What am I supposed to now? I tried disabling javascript in my browser but of course that won't let me modify the blocks either.
I don't know 5.8+ that well yet, but this may be unfixable from within the UI.
If the error is in a global area, your best bet might be opening the template, changing the area name where the global area is used and displayed, and recreating it from scratch.
You'd be looking for something like this:
$a = new GlobalArea("Footer Nav");
and change the global area's name, thus creating a new one.
If that's not an option, you may have to resort to deleting (or altering) the faulty block through the API.
In my experience, the easiest way to get a blank page that has C5 bootstrapped is creating a custom Dashboard page:
It's a common task for a Concrete5 developer to create their own Dashboard pages. Dashboard pages are just single pages located inside the "single_pages/dashboard" directory. Once they're added within that location, they automatically show up in the Dashboard.
Now, as to how to edit or delete the block inside the area, I don't have a complete recipe, but this example page showing advanced area operations should get you started.
The API documentation for GlobalAreas is here, for Block here (notice the delete() / deleteBlock() methods.)
FYI although the solution marked as best works, it leaves data in the database that will stay there forever and forces you to change your area's name which might be ok once but not if it happens again and again.
Since that was an HTML block, the best way was to go to your database's interface, probably phpMyAdmin, go into the table "btContentLocal" and do a search for the faulty code you had entered in the HTML block then fix or delete it.
Like that you're back to normal, you don't leave stuff behind, and you can keep your area as it is
I am trying to make a tabbed windowing system within a webpage using om-bootstrap's "pills" navigation by adding tabs when links get clicked and removing tabs when an X button on the tabs is clicked.
I need to know how to add and remove data from the global state/store and create a macro that can be used to declare a tab app component and make it remove itself when it is no longer alive.
What is the best way to reference the global state? How can I make a component remove/unmount itself when it gets closed?
Since removal of a subcomponent affects its owner, you should let the owner (i. e. the "tab system") know that this tab needs to be closed/destroyed/obliterated.
I've digged through todomvc example (live) assuming your process of destroying tab panes is pretty much the same as destruction of TODO items there. I see nothing ocnflicting so far. Here are my findings:
A channel is used.... When application starts (IWillMount), a (chan) (from core.async) is written into application state at :comm key.
...for event handling.... Events from the channel are handled in the loop following that code, in go-form, asynchronously with the block it appears in (with <! being a "kinda blocking" operation). Well, you may know it, I didn't, still learning what is CLJS all about.
...that is passed to all child items' init states.... So it becomes a way for children to send events to the root. I'm starting to like this.
...so they can send events to their parent! This is done in put! calls with the comm channel, fetched in the linked line. Events put there are handled by the loop defined in (2), which delegates them to appropriate functions depending on type (accompanying keyword).
I'm nowhere near a ClojureScript pro, but I'm learning. So if the above doesn't make sense, this is normal and means I didn't understand something. If that turns out to be the case, putting me back on track would be much appreciated.
I'm working on a heavy e-commerce app. In such apps tracking is a huge concern. It's crucial to know if users use feature x or click on button y etc.
For instance let's say you can bring up the search either by clicking on a search button on the header or by a app wide keyboard command CTRL + S.
Now if we want to track such things, how would be the best way to handle it. I ponder and dither between (using pseudo JavaScript here but the language doesn't really matter):
1. Just do the tracking directly where the action happens:
function searchButtonClicked{
//this event will be raised anyway to be catched somewhere else to bring up the search
raiseEvent('searchButtonClicked');
//now directly track the stuff here
trackingService.trackEvent('searchButtonClicked');
}
And...
2. Just raise events for the actions and then catch those in the trackingService
function searchButtonClicked{
//this event will be raised anyway to be catched somewhere else to bring up the search
raiseEvent('searchButtonClicked');
}
...and somewhere in trackingService
onEvent('searchButtonClicked', function(){
track('searchButtonClicked');
});
So on first glance 2. seems a bit nicer to me as none of the components need a dependency against the trackingService. They don't even know that tracking exist. In addition some of the existing events can probably be reused. However that only helds true for a small subset of events. Most events would be raised more or less exclusively for the sake of tracking. So I wonder if that layer of abstraction is really necessary?
Such tracking doesn't seem to be much different from logging and I think it's accepted practice to directly log at the places where the events happen, no?
As always, it depends on your specific case.
If, like you say, most trackable operations in your application don't raise an event, then an abstraction using events is not the best option.
you could just have your code call the tracking directly, which is not the most clean thing, but it's the simplest, and if each call is just one line, as above, is probably acceptable.
I can just suggest one more little thing- you could try AOP.
depending on the technology you use, you could, either-
1. Mark certain classes / methods for tracking (maybe using attributes, or whatever) OR
2. Create a class that would hold the list of all the classes / methods to track.
If you are doing this in JavaScript, using some library like JQuery can make your life easier. Otherwise you need to have a event registration and listener mechanism in your code.
check here of examples under bind() function
$( "#searchButton" ).bind( "click", function() {
track('searchButtonClicked');
})
First of all, it is possible?
Second, make something like coordinates in JS. For instance, 300 margin-top, 500 margin-left; make a click with the same effects and values than a normal mouse track in a laptop click.
Last, I don't mean onclick="", onmousedown="" etc. what I'm saying is an action/effect of a user click.
Thanks.
PS: if JS can't make this, another method can be done will be?
.swf objects are mostly a blackbox for javascript. You can "listen" to some stuff in some cases (to an extent, things like when a video is played/stopped etc..but this is not 100% for all browsers/versions, and also depends on how the .swf object is invoked). But "listening" general "actions" within a .swf is not possible with javascript. Depending on what you want to do, you can effectively get the same thing..sometimes...like for instance, detecting a position inside a .swf object someone clicked...if you add an invisible html layer over the object, you can look for some things like clicks and even positions (in some cases).
But overall, the only real accurate way to do it is to add tracking/listening functions within the .swf object itself (which means you will need access to the .fla source file to add and re-compile to .swf). And you use ActionScript for that (Flash's scripting language). But you CAN make external js calls from within .swf object, if you need to pass info to js. But again, this involves putting code inside the .swf
I was wondering if there is any way to find all the scripts associated with a particular element in web page.
That is if there is a photo, and there is two attached jquery function like on mouse over and on click, I need to get details of this functions without looking onto entire script.
One way is with a bookmarklet called Visual Event
There isn't really an easy way. I spent a few days trying to write an augmentation wrapper/extension that would track all even assignment in page and thus allow for inspection of such - the problem is that it requires tweaking for each library, and iirc wasn't useful if any native event assignment was used.
This is exactly the reason there needs to be well organized code, and remembering that "unobtrusive" doesn't mean "incomprehensible" - try to keep all your event assignments well organized and easily associated/found for a particular element.