After upgrading to 2.0 many "hacks" like accessing protected attributes are not possible anymore.
For example (AssetHelper):
$scripts = $this->View->_scripts;
//pack and return combined scripts
The helper fatal errors, of course.
Does anyone know how to access those attributes in 2.0 without creating too much overhead in the process?
Are the AssetHelper and other such classes outdated if they try to access the View from inside a Helper?
The new way of accessing the View from a Helper in 2.0 is $this->_View which is protected. You can see it on the Helper API page.
I looked at the AssetHelper on Github and it is outdated. It still retrieves the view from the ClassRegistry instead of the new method. It also accesses the __scripts attribute of the old 1.3 View class which wasn't actually "private". I think you're correct that the change to real visibility declarations has broken this use.
Just brainstorming, but I wonder if you could make your own View class that has a getter for the _scripts attribute like $this->_View->getScripts(). I know that in 2.0 they added a slick ability to alias core classes; while I think this is restricted to helpers, components and behaviors it's something to think about.
Hope that helps.
Related
I'm writing a small application in CakePHP 2.1, and I want to use Nick Baker's file upload plugin. I downloaded the cakephp2.0 branch (I know that isn't done yet), and placed it in my apps Plugin folder. I made some necessary modifications on it, but I'm curious what the right way is to replace those App::import function calls (at start of FileUploadComponent, FileUploadBehavior and FileUploadHelper classes) with the App:uses function.
It needs to import the FileUploadSettings class from Config/file_upload_settings.php and the Uploader class from Vendor/upload.php. It can be done with the require_once function, but I'm sure there is a CakePHP way to do it.
From what I've gathered:
use import() for external libraries
and uses() for framework files
For example:
App::import('Vendor', 'ExternalLibrary');
App::uses('Inflector', 'Cake.Utility');
According to the Cake manual App::import() is comparable to the way require_once() works. From what I understand you would load classes using App:uses() and Vendor files using App:import().
The API documentation says the following on the subject:
All classes that were loaded in the past using App::import(‘Core’, $class) will need to be loaded using App::uses() referring to the correct package. This change has provided large performance gains to the framework.
The method no longer looks for classes recursively, it strictly uses
the values for the paths defined in App::build()
It will not be able to load App::import('Component', 'Component') use App::uses('Component', 'Controller');.
Using App::import('Lib', 'CoreClass'); to load core classes is no longer possible. Importing a non-existent file, supplying a wrong type or package name, or null values for $name and $file parameters will result in a false return value.
App::import('Core', 'CoreClass') is no longer supported, use App::uses() instead and let the class autoloading do the rest.
Loading Vendor files does not look recursively in the vendors folder, it will also not convert the file to underscored anymore as it did in the past.
The migration guide also has some things to say about App:uses() and is a good starting point in general to compare best practices for 2.0 with the older methods from 1.3 and lower.
This related question deals with loading Vendor files in Cake 2.0, I can't verify the claim by José Lorenzo that App:import() is a "silly wrapper" for require_once(), nor the statement that it's the preferred way of including files. The only reference I could find for the latter is in the Coding Standards for Cake contributors, viz. developers contributing to the Cake core, not applications built on the framework.
EDIT
Let's say you want to import the Twitter OAuth library, residing in Vendor/twitter, the main class file is twitteroauth.php in Vendor/twitter/twitteroauth/twitteroauth.php:
App::import('Vendor', 'twitteroauth', array('file' => 'twitter'.DS.'twitteroauth'.DS.'twitteroauth.php'));
Project Structure
I have a silverlight project SLProj, that references a silverlight class library project called ServiceClients. ServiceClients has two wcf service references, Svc1.svc and Svc2.svc. Both Svc1.svc and Svc2.svc are in two different WCF projects which use the same set of DataContracts which are again in a different class library project called MyDataContracts.dll.
Problem description
Now in my ServiceClients project I get an ambiguous reference issue when I need to use a datacontract class which is present in both the service references. If this were a winforms or webforms project, I could reference the MyDataContracts.dll and reuse the common types. But since, this MyDataContracts.dll was built using a non silverlight class library, it can't be referenced in the silverlight project
Workaround...
I am not sure if this below is the best method to go about taking care of this issue. Can anybody let me know if there is a cleaner way to solve this problem, or is this the best way we have so far?
create a single service reference.
click the 'show all files' button in the solution explorer
drill into the service reference and find Reference.svcmap and open it
find the MetadataSources section
add a second line to include the address to your second service. for example:
MetadataSource Address="http://address1.svc" Protocol="http" SourceId="1"
MetadataSource Address="http://address2.svc" Protocol="http" SourceId="2"
save, close, and update service reference.
Use Automapper
Map the DataContracts with AutoMapper.
You will have to invest some time in understanding AutoMapper and reworking your application. Also AutoMapper adds overhead because all data objects will be mapped. But first you will have a clean solution without hacks and second you gain a decoupled and simple data object layer just for your client. Once done you can forget the mapping but you stay flexible for future changes.
If you never have worked with Automapper it's important to play around with it before starting. Automapper is special and needs some time to familiarise with it.
So there. These are the rough steps:
1. Create a subdirectory and sub-namespace Data and copy the DataContracts. Remove the attributes and properties your client doesn't need because these mapped classes live only in your client. You can also change some types or flatten some complex properties.
2. Create an AutoMapperInit.cs like described at Automapper (read the Getting Started Guide). Use the conflicting references like this:
using ref1 = YourProjectServiceReference1;
using ref2 = YourProjectServiceReference2;
3. Wrap the service client like this:
Example GetExample() {
return AutoMapper.Map<ref1.Example, Example>(ref1.YourService.GetExample());
}
The wrapper also needs the same using directives as in step 2.
4. In this wrapper add a static initializer like this (assuming your wrapper class is called Wrapper):
static Wrapper() {
AutoMapperInit.CreateMaps();
}
5. Omit service references in the client and use using YourClient.Data;, the namespace you created in step 1.
Your client is now decoupled from the service and you don't have conflicts anymore.
Disclaimer: I am not affiliated with AutoMapper. I just used it in a project with a similar problem and am happy with it and wanted to share my experience.
Your workaround is actually quite OK. We've used it in several projects like this with 3 service references. It is actually a workaround for the IDE which for some reason only allows to select one service to create a service reference at a time.
Another thing you could try-out is to multi-target your shared contract to .NET and Silverlight, using the same codebase. Details on how to do such thing is described in http://10rem.net/blog/2009/07/13/sharing-entities-between-wcf-and-silverlight. Might be more work but feel less hacky.
I'm all new to magellan, and as an attempt to learn it, I've built a custom view engine for supporting windows forms as specified in the documentation at codeplex.
But how to register this new ViewEngine? There it is given,
ViewEngines.Engines.Add(new FormsViewEngine(new DefaultViewActivator()));
But what I can see is that, ViewEngines is not a Static Class and moreover it does not have a Engines Property. I know I'm missing something, but what is it?
So, How to register my ViewEngine to Magellan? Where and When should I register it?
PS: I'm using the latest update of magellan.
You are correct, the view engines are now configured on the ControllerRouteCatalog.
One of the goals in Magellan 2.0 was to reduce the number of static locators.
Seems like things have changed a bit. A few search for references of ViewEngine Class in the Magellan source gave the answer.
Now ViewEngines just provide default collection and no more handles ViewEngine registrations. I managed to create my own ViewEngineCollection and pass it to the contructor of ControllerRouteCatalog.
My bad, I should have done that before. Thanks anyway.
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
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.