Is it possible to use a collection without any interaction with a server? I know backbone has a local storage option but I'd rather not use that.
Yeah, definitely! There aren't a lot of rules when it comes to Backbone, and requiring you to interact with a server isn't one of them.
The fetch() and create() methods for collections require a url in the collection definition, but if you don't use those methods, you should be fine. For models, avoid fetch(), save(), and destroy().
If you do need those methods for some reason, you can just set collection.url = '/' and it just won't do anything.
Yes, you can use it entirely in memory if you like.
Related
I need to define common functions for managing a mySQL DB: updating, inserting, deleting functions to be used in several different pages of the WEB site. Since generally the access to DB is defined in models, I wonder if in case of common functions managing a DB it is possible and makes sense to define them in helper instead in a model of a specific page.
Those functions shouldn't be in a helper but in a extension of your CI_Model.
You can create a new class in your application/core folder and create a MY_Model.php file.
That class should extend to your CI_Model. Then all your models will extend to MY_Model instead of CI_Model.
If you're looking to automate that kind of crud functionality you might want to look into something like this that has everything you need and more:
Codeigniter MY Model
This is a deprecated model, but you can check what can be done or even clone it and maintain it yourself.
I'm currently learning ExtJs, but I can't seem to grasp my mind arround the following.
What is the difference between the array notation and the requires notation
For example:
view['MyPanel']
model['MyModel']
controller['MyController']
store['MyStore']
requires: ['namespace.view.MyPanel']
Do they do the same or ... ?
And why do I have to put ALL the views, models, controllers and stores used in the application inmediatley in the app.js?
Can someone clear those thing out to me? :)
Requires will just load the files matching the class name from the server. It will not instantiate anything. You should require what is needed in each view/controller/model, you don't need to have it all in app.js.
For instance, if you have a MyModel that has a relation to MySubModel, then MyModel would require MySubModel. Requires is essentially about loading other classes when needed so that they are fetched from the server before being used - since using a class when it is not loaded creates a noticable delay due to ExtJS having to fetch the class from the server before instantiating it.
The models, views and controllers arrays in a controller are a convinient way to require such resources as you don't have to specify the path to the models/controllers/views folders. See the docs on controller models config for example.
A guide on how to structure your application is available here even though I don't really like that they load all views and all controllers in this approach. But it's a good start. You can dynamically load stuff later on when your application grows.
I'm developing a CakePHP application that we will provide as a white label for people to implement for their own companies, and they'll need to have certain customization capabilities for themselves.
For starters, they'll be able to do anything they want with the views, and they can add their own Controllers/Models if they need to add completely new stuff. However, I'd rather advise against touching my controllers and models, to make version upgrading easier.
Esentially, the customization capabilities I'm planning to give them are going to be quite basic, I just need to call "something" when certain things happen, so they can do things like update external systems, e-mail themselves/the clients, things like that.
I'm wondering what's the best way to do this?
My plan is to have a "file" (with one class) for each controller of mine, to keep things reasonably organized. This file will have a bunch of empty methods that my code will call, and they'll be able to add code inside those methods to do whatever they need to do.
The specific question is, should this class full of empty methods be a Component? A Controller? Just a regular plain PHP class?
I'll need to call methods in this class from my Controllers, so I'm guessing making it a Controller is out of the question (unless maybe it's a controller that inherits from mine? or mine inherits from theirs, probably).
Also, I'd need the implementer of these methods to have access to my Models and Components, although I'm ok with making them use App::Import, I don't need to have the magic $this->ModelName members set.
Also, does this file I create (etiher Component or Controller) have to live in the app folder next to the other (my) controllers/components? Or can I throw it somewhere separate like the vendors folder?
Have you done something like this before?
Any tips/advice/pitfalls to avoid will be more than welcome.
I know this is kind of subjective, I'm looking to hear from your experience mostly, if you've done this before.
Thanks!
Two ideas that spring to mind:
create abstract templates (controllers, models, whatever necessary) that your clients can extend
write your controllers/components/models as a plugin within their own namespace
Ultimately you seem to want to provide an "enhanced" Cake framework, that your clients still have to write their own Cake code in (I don't know how this goes together with your idea of "basic customization capabilities" though). As such, you should write your code in as much an "optional" manner as possible (namespaced plugins, components, AppModel enhancements, extra libs) and provide documentation on how to use these to help your clients speed up their work.
I would setup a common set of events and use something like the linked to event system to handle this.
That lets the clients manage the event handler classes (read the readme to see what I mean) and subscribe to and broadcast events application-wide.
Also - if you want to have your users not muck about with your core functionality I recommend you package your main app as a plugin.
http://github.com/m3nt0r/eventful-cakephp
I am working on a WPF application, using the MVVM Pattern.
Each ViewModel will need access to a security object, that essentially provides information about the rights the user has. Because this object only needs to be populated once at start up, and because populating it is (at least potentially) expensive, I want to keep it in state for the lifetime of the application.
I can make it a static variable in App, which would make it available to the whole application (at least that's my understanding). This would make my ViewModel implementations very difficult to test, since the App.SecurityObject call would be inline in each ViewModel. I would have to make sure App was available for each test and mock the App.SecurityObject call (I'm not even sure this would work, actually).
We are using StructureMap, so I could create a SecurityObjectProvider and configure a it with a Singleton lifecycle in the container, and simply make it part of every ViewModel constructor. The downside would be that (as I said) the provider would have to be part of every View Model constructor.
There are other, hacky workarounds I can think of, but they would involve creating methods (perhaps in the View Model base class) that would allow injecting the security object after instantiation for testing purpose only. I usually try to avoid this kind "for testing only" code.
It seems like this would be a common problem , but I can't find any SO questions that are completely on point.
Security concerns are often best adressed by Thread.CurrentPrincipal. If it's at all possible to fit your security concerns into that model (calling Principal.IsInRole and so on) that is by far the desirable solution.
It's pretty easy to unit test because you just need to set Thread.CurrentPrincipal before invoking the SUT and then make sure you revert it to its original value in the Fixture Teardown phase.
If Thread.CurrentPrincipal doesn't suit your need, I would suggest either an injected dependency or a Decorator that handles security. Security is often a Cross-Cutting Concern, so it is often preferable to handle it as declaratively as possible. In other words, if you can model it by Guards and Assertions, you don't need to actively call it, and you would be able to use a more AOP-like approach (such as a Decorator).
If that's not possible either, you can model it as an Ambient Context. This may look a bit like the Service Locator anti-pattern, but the difference is that it's strongly typed and has a Local Default that ensures that it never throws NullReferenceExceptions or their like because it protects its invariants.
The service locator pattern might help you out. You still implement the functionality as a service, but you have your VMs go through a static class to obtain the service, rather than have it injected:
var securityService = ServiceLocator.Resolve<ISecurityService>();
When running unit tests, you can configure your service locator to return mocks/stubs.
I think I would use some kind of Service Locator to get object. And in tests I would mock it out.
In my application I did not have model.am using webservice for data.To handle the exception I need use $this->invalidate from controller. Without model how to use that?
Thanks
invalidate() is a method from AppModel, so it must be called against a model. If you're doing validation, why aren't you using a model?
For using a webservice other patterns work much better. For example you could build a custom datasource:
http://book.cakephp.org/2.0/en/models/datasources.html
That's the best solution in most cases. Now you put everything in a controller and that will cause issues.
So the advised structure for the data flow is:
datasource -> model (with optionally a behaviour) -> controller
If it's a common webservice I would suggest that you put the datasource in a plugin to seperate it out. Like: https://github.com/cakephp/datasources as an example (be aware they're a but old). See for example this one as a more recent: https://github.com/dkullmann/CakePHP-Elastic-Search-DataSource
In general you tried to put all in the controller to keep it simple I suspect but it is advised to structure it according to the framework.