This copy paste functionality is however smart adaptive powered by a strong AI. It adapts to your needs.
If you need to copy the key, value and storage type to a string of text it is sufficient to right click on a storage, select copy from the context menu and paste the string into your favorite text-editor. Nothing new right?
Wrong. Try to paste the same copy in the FireStorage Plus! panel and you will get a duplicate storage key added with a counter suffix to avoid collisions. However if you paste the storage into the panel on a different host the exact same storage will now be set on the new domain / website.
This is very useful to transfer storages between different environments by the means of a simple copy paste.
This is an excellent feature to maximize your development regarding web storage.
Go ahead try to copy paste the storages within the panel accross different sites / environments.
Thanks for reading and I wish you nice adventures with HTML5 Web Storage.
What is the Firefox Add-on “FireStorage Plus!” all about?
First It is about you!
Secondly it is about HTML5 Web Storage mechanisms.
Where can I find it?
First you need the Firebug addon: https://addons.mozilla.org/en-US/firefox/addon/firebug/
Then you need the FireStorage Plus! addon: https://addons.mozilla.org/en-US/firefox/addon/firestorage-plus/
The FireStorage Plus! addon is an extension to the wonderful tool Firebug.
Why would I need it?
You cannot imagine how many companies – such as Google, Facebook, Twitter, and so many more – use HTML5 web storage to store information about your usage and their interface. With this tool you can inspect that storage and know exactly what they are storing.
Does it work for developers?
For developers it goes even further by showing you the storage mechanism that has been used to store the info. With a quick glance you will be able to spot whether it has been stored in sessionStorage – in which all information will be removed when you close your browser – or in localStorage – in which the information stays infinite or till the site decides it can drop the info.
What kind of improvements can I expect in the near future?
This is off course the first version (V1.0) and it provides all basic information you need with nice JSON formatting.
However we (Me and the contributors) are working hard to also provide in order of importance:
- real time editing and deleting of this information.
- a JSON tab – which will let you unfold different parts of information from the stored JSON object instead of seeing it as a big chunk of text.
- some layout improvements
- indexedDB support
It this addon safe?
Yes it is. The plugin has had a FULL review by members of the Mozillas review committee. Which means they had a look at the code and found it to be clean and ready to be featured in their addons-gallery. Take a look at the source code yourself if you want to check: https://github.com/NickBelhomme/firestorageplus
How do I contribute?
- If you are non-technical you can email me with great ideas and who knows maybe your idea will popup in the next version.
- If you are a developer you might take it a step further and send me code patches / improvements. This can be done through Github, but I also accept regular files through email. I do not care how you submit your implementations I only care about the final result.
What do users say about this addon?
I submitted this addon towards the Mozillas review committee and somebody must really like me or understand the importance of this plugin as it was FULLY reviewed under 24 hours. The first 5 stars review(s) came pouring in shortly after that.
I hope you take the time to try it and give me your feedback,
This weekend (27-28 January 2012) I spoke again at the PHPBenelux Conference and what a sweet conference this is.
An excellent line-up, great organizing and a wonderful networking opportunity. You should attend in 2013, if you are still doubting here are the reasons what made 2012 so special.
Purpose of the entry
Writing about this conference makes my heart jump and grin from ear to ear. I am obliged to write about this event just to vent all the positive feelings I have about this conference. I hope I will be able to give you just a taste of what I am feeling.
- What is #phpbnl12?
- My talk PHP traits, treat or threat
- Who was attending?
- Pros and Cons of this year
What is #phpbnl12?
The PHPBenelux Conference is a two day event organized by PHPBenelux which is a non profit PHP usergroup oranization for the Benelux. They organize meetings and conferences for PHP developers and companies using PHP. These events contain technical talks, workshops and best-practice sessions to share and improve the knowledge among developers. And that is exactly what this yearly conference is about: workshops, best-practices and sharing knowledge among developers.
This year was the third installment of many more to come and was perfectly organized by the PHPBenelux Crew (professionalism for the win).
They managed to get together an excellent schedule full with talks ranging from beginner to advanced. Found some killer sponsors which in turn threw some spectacular after socials. Ibuildings organized a Belgian beer tasting – without the spit-bucket, so you can imagine how that went – and combined that with real Belgian fries. They tasted soooooo good. You had the opportunity to play the Kinect but also could get your hands dirty on some good old Bowling. I kicked the ass of Derick Rethans, David Zülke, Stefano Oldeman and Jeroen Keppens. Unfortunately got my ass kicked by (the lucky cheating bastard ) Juozas Kaziukenas in the last round. That was so exciting 123 – 116. Maybe next year dear reader you can challenge me!
The other great sponsor was Engine Yard (Orchestra) and they arranged a BBQ. Those guys know how to entertain and luckily for me they also thought about the vegetarians. I scored a free Engine Yard scarf – which was needed because it was a blistering cold – and scored couple of drinks from some awesome people.
Talking about these social events is important because a conference is soo much more than learning. Hell there is tons to learn but also tons of interesting people to meet.
My talk PHP traits, treat or threat
This talk is an invitation for you to finally embrace PHP5.4. Normally you should already master all the 5.3 features. Heck it has been around for ages to play around with in production. The stable release of PHP5.4 is just around the corner so you should already have been testing all your apps against it. If you haven’t come and see this talk why. It will throw in some new PHP5.4 features / syntax but will of course mainly focus on traits.
The talk in itself was packed with information based on real world examples. This made the slidedeck sometimes spill with code, which I will filter down to a more readable and thus understanding level (got some complaints about too much code confusing it all). The reason why real world examples are chosen is simple: the attendee gets immediate feedback on how and potentially where to use it. He/She sees the possibilities of the feature instead of some academic foo bar examples, for which they can read the manual on php.net. However even if they are more into academic examples they found my slides and presentation far exceeding that. Lets be honest the manual is lacking a lot of information on what is possible with traits. For this you need to really invest in the mailing lists and talk to the PHP core team. That information is in the slides. The talk doesn’t say traits are the holy grail nor that it is evil, I let the attendee decide. I show what is possible with this new language feature without any judgement, but do focus on some best practices and pitfalls.
- I think Nick did a great job and I learnt a lot of new stuff.
- I liked the fact that it was “real code” and not just hello world examples.
- I really enjoyed this talk. Really looking forward to give 5.4 a try
- This was a talk I was really looking forward to. Nick did a good job at explaining traits.
- Very interesting talk; I learned a lot of new stuff and I’m definitely going to play around with traits a bit more
Who was attending?
Approximately 300 attendees with the “open source state of mind” at heart joined the conference. People who love to learn or lecture on everything programming related. It is about so much more than PHP. I urge you to join even if you are programming into a different language like .net or java. There is a wealth on information at this event and you feel the positive vibe of each and every attendee. The sponsors gave away some cool gifts too. ibuildings gave several tickets to DPC12 -another high rated conference- and an iPad2. Enrise raffled several Zend exam vouchers and an Apple Macbook Air (how f* awesome is that??).
Pros and cons this year
- As always excellent venue
- lots to learn at great lectures
- lots of awesome people who are happy to meet you
- sponsored conference social drinks at the hotel => FREE DRINKS for everyone.
- the food really went up a notch this year. This year warm meals were also available and they were Yummie.
- 2 small rooms and 1 main room doesn’t cut it anymore for this conference. At times some of the small rooms were packed. I had to stand at some presentations and during my talk people litterly sat on the floor. I do not know the proportions, but if the room at a seat capacity of 100, then at least 40 extra sat on the floor in front of the chairs.
Great value for money and in general a conference you should attend, no excuses.
See you next year at The PHPBenelux Conference 2013
Thx for reading and feel free to comment,
Dearest Zend Framework and PHP Addict,
You know I always try to keep a close watch on the developments of Zend Framework 1.* and Zend Framework 2.0. Today I will blog about the Dependency Injection Component that is going to ship with ZF2.0.
What is dependency Injection?
You have been using dependency injection from the first time you started using classes. After this article you will have an ah-aaaah moment and you will finally be able to name the practice you have been doing all along. Almost each class has dependencies to other classes. You could instantiate these dependencies inside the class itself, making sure the dependency is always met, also avoiding the overhead of injecting it each time. While this seems a good idea in the beginning, it also tightly couples your application units. Also the quality is harder to guarantee because during unit testing your code has dependencies which are instantiated from inside the class to be tested. This makes it very hard to manipulate the state the dependency might have. The solution is to never instantiate the class from inside the class itself but from outside and let it be set as a parameter.
A good PHP resource on why you need dependency injection in PHP can be found at Ralph Schindlers blog article: Learning about Dependency Injection and PHP
What is a dependency Container?
Having to instantiate and pass the dependency all the time can be troublesome to say the least.
The first PHP solutions were to have a registry which would hold all the instantiated objects and only this registry would be tightly coupled in your architecture. This went a long way but still tightly coupled your architecture.
To remedy this people started looking into a good component which could really hold dependency definitions – a configuration which holds all classes / methods and their dependencies. And would also hold an instantiator, and container. The Instantiator would instantiate the objects for you according to the definition and a container would hold previous instantiated objects.
A good article written by Padraic Brady and published in 2008 pens down this idea and proposes a Zend Framework Dependency Injection Component, or simply Zend_Di: The Zend Framework Dependency Injection And Zend_Di
The Current Day: Zend\Di
Zend Framework 2.0 is currently under full development, several milestones have been completed. Probably the most important milestone of ZF2.0 is the MVC. To be fully compliant to current standards a good Dependency Injection (DI) component had to be developed.
_Why_ does ZF2 need DI for the MVC?
The reason is that it’s a good potential answer to the question of “how do controllers gain access to their dependencies?” In ZF1, the answer was either indirectly via Zend_Registry or the Bootstrap together with getInvokeArg()), or via direct instantiation within the controller. The latter is problematic as you can’t easily provide substitutions, and if the class instantiated needs to interact with resources — say, a web API, the database, etc. — this becomes difficult to mock when testing. In the former cases, you’re introducing undocumented dependencies in the object — looking simply at the controller’s API, you cannot easily guess what other objects it uses.
DI helps answer this. The prototype Zend Framework Core Team started building assumes that a DI container is composed into the front controller, and controllers are themselves defined in the DI container. When a controller is matched by the router, the front controller then pulls the matched controller from the DI container — along with all of its dependencies. This helps solve the initial question, but also answers another one: how to reduce the number of objects necessary for each given request. In ZF1, every single application resource is instantiated on every request, regardless of whether or not a controller uses it; the DI approach largely removes this, though at the expense of an in-memory graph of object definitions. However, the latter is usually smaller over-all, and easily cached in memory.
Ralph Schindler (Part of the Zend Framework Core Team) takes the lead on this component and listened to the community. He poured all those ideas in a component that can take prior configured definitions, detect dependencies at runtime and a tool for static dependencies analysis.
The approach that has been taken is that different environments will behave differently from a DI perspective. The solution is to consider anything but your local development machine production. Application in production should be stable from a code perspective and unchanging code means the deploy tool should be able to statically parse your code and create a definition file from it. This can be done automatically on each deploy. Once a definition file is ready – this will be in PHP format for maximum efficiency – your application doesn’t need to analyze your code on every request, thus gaining in huge performance benefits and without the hassle of always manually configuring all dependencies. Of course some dependencies will have to be manually configured, but Zend\Di offers tools for that.
Let’s take a closer look at the tools Zend\Di offers.
This class will be instantiated most of the time. It will be used to retrieve instances configured by a definition.
For this you will need to set the definition object or manually configure everything piece per piece.
$di = new Zend\Di\DependencyInjector(); $di->getInstanceManager()->setParameters( 'My\A', array( 'password' =>'bar', 'username' =>'foo', ) ); $c = $di->get('My\C');
In this example class C is instantiated. Class C has a dependency on class A, This is automatically behind the scenes detected by Zend\Di\Definition\RuntimeDefinition. Yet class A has constructor dependencies also, which can never be automatically injected so for this we need to set these parameters. This means that we need to aggregate all dependencies which cannot be automatically instantiated into a definition file. Even automatically detectable dependencies at runtime would benefit from a definition because compiling shouldn’t be done at runtime — it’s expensive. You will typically compile once, and then create a class extending ArrayDefinition that uses the results of compilation.
Creating a definition file asks a lot from a developer so it would be best that it could be automated as much as possible. For this a static compiler is implemented. Which has stated before should not be done at runtime during production.
$compiler = new Zend\Di\Definition\Compiler(); $compiler->addCodeScannerDirectory(new Zend\Code\Scanner\DirectoryScanner(__DIR__ . '/Game/')); $definition = $compiler->compile(); $di->setDefinition($definition); $commandParser = $di->get('Game\CommandParser');
$definition will be a complete Zend\Di\Definition\ArrayDefinition which accepts and outputs a PHP array based definition.
You can only have one definition at a time – hence the setDefinition and not an addDefinition api – so calling setDefinition() and passing an ArrayDefinition will result in no more Runtime lookups. If you want to combine the two strategies, you need to use an AggregateDefinition. An AggregateDefinition acts as a queue, querying each attached definition until it finds a match (or doesn’t!). As such, you would attach any compiled ArrayDefinition objects first, and a RuntimeDefinition object last.
Combinations of a definition and setParameters are also possible:
$di->setDefinition($definition); $di->getInstanceManager()->setParameters( 'Game\Grid', array( 'gridSizeX' => 2, 'gridSizeY' => 5, ) ); $commandParser = $di->get('Game\CommandParser');
Parameters set through options or through the setParameters method are not only used for the __construct method but also for the available setters. This makes your code a bit hard to understand because you have no idea which parameter is used for what method. So parameters are nice, but the current incarnation also allows specifying per-method configuration for parameters that should be called at instantation (i.e. setter injection). In fact, it’s the preferred method for specifying configuration even for the constructor.
$di->getInstanceManager()->setMethods( 'Game\Grid', array( '__construct' => array( 'gridSizeX' => 2, 'gridSizeY' => 5, ), 'setPosition' => array( 'x' => 1, 'y' => 3, ), ) ); $commandParser = $di->get('Game\CommandParser');
In the case where CommandParser needs to automatically accept a Grid object as a constructor parameter, you can even pass the constructor params for Grid directly to the get method of the main class:
$commandParser = $di->get( 'Game\CommandParser', array( 'grid' => array( 'gridSizeX' => 2, 'gridSizeY' => 5, ) ) );
The Injector will inspect the constructor params for CommandParser and if it doesn’t have a $grid param, than it will save the param for creating a params instance that might need it. In this case the Game\Grid $grid. This way you can pass params all the way down to the last dependency needed for instantiating the class you asked.
Or to make it even a bit more flexible you can even create aliasses and pass them as the second parameter.
$di->getInstanceManager()->addAlias( 'my-Grid', 'Game\Grid', array( 'gridSizeX' => 2, 'gridSizeY' => 5, ) ); $commandParser = $di->get('Game\CommandParser', array('grid' => 'my-Grid'));
Aliases are intended to make it simpler to specify dependencies and/or substitutions. As an example, I might alias Game\Grid to “my-Grid“, allowing me to call $di->get(‘my-Grid’) and retrieve that class. This means that I could potentially configure the container differently, and get an object of a different class later — which is very useful for testing, or having different adapters for different environments.
So this is basically the standard usage of the Dependency Injector. Of course the DI is still BETA, and it shows.
Zend\Di leans heavily on Zend\Code\Scanner and here are still some caveats. At the time of writing the MethodScanner or ParameterScanner needs to be fixed to allow for the method signature:
public function __construct(Request $request, Response $response, Grid $grid, Inventory $personalInventory)
At the moment this signature breaks because of the start of the tokens for each Parameter.
It does however accept:
public function __construct(Request $request,Response $response,Grid $grid,Inventory $personalInventory)
As you can see the whitespaces between the parameters have been removed. Bottom line the Scanner should not be so error prone.
For my own testing I have forked ZF2 and fixed this issue in the branch https://github.com/NickBelhomme/zf2/tree/bugfix_tokentrim
As you can see all is still under major development, but that doesn’t mean you cannot play with it. So if you are interested in learning something about Dependency Injection and maybe even ZF2 in general I suggest you take a look at it.
I had a lot of fun inspecting the component and a lot of banging my head into the walls for comprehending the stuff described above. And honestly I couldn’t have completely grasped it without the excellent help and feedback of two special people deeply involved in this project: Matthew Weier O’Phinney and Ralph Schindler. Thank you both for the feedback which helped me in writing this blog post and spreading the knowledge.
A good code resource to mention is a forked and brought up to date repo with the current ZF state: https://github.com/NickBelhomme/ZF2ByExample
Sunny Greetings From Belgium and happy Zend Frameworking!