I downloaded the new version of Zend Framework 2.0 and noticed that it has less features than the version 1.2, both in framework folder and externals.
What is the reason? Does Zend have a new policy to you include some features as extensions or this is related to become more lightweight?
Zend_Service(S) now have each one his own repository with his own live cycle, by this way that services can be adapted soon to the vendor API changes.
Zend_Date, Zend_Currency, ... and other locale components have been replaced by PHP 5.3 API (DateTime, NumberFormat, etc) there is a new i18N component for translates.
Other components was not in use, and others are not enough stable for to go with the main distro.
Here you have the full list of repositories for the main distro and other components https://github.com/zendframework/
In zf2.0 only standard components are included, the components that are essential for the application development. The remaining components can be included on-demand.
You can read more about this in http://framework.zend.com/downloads/
The reasons for making this such lightweight is explained by Matthew Weier O'Phinney http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Requirements
Related
When I say CQ5 I mean the version 5.5.
I would like to know the major differences in features.
I have seen AEM 6.0, the core of it is the same as CQ5. I checked out the examples, all the examples are the same, the only difference I found was the UI of WCM i.e. there is a new look and feel for it but you can still switch to the classic mode.
CQ5 still encourages coding in JSP i.e. it still uses scriplets.
Is there any alternative to using Scriptlets in AEM 6.x?
I feel Adobe just changed the look and feel of CQ5 and they have released a new version of it called AEM 6.x
What are the killer features of AEM 6.x that are not there in CQ5 ?
I would recommend you to take a look for release notes
I like below features quite a lot:
A new repository Apache Jackrabbit Oak.
Sightly, a new templating language that way you can avoid scriptlet code to a great extent.
Supporting better user management by delegating the permissions.
Create projects wizard & project templates
The above ones are very few which I have highlighted. There are many more so as per my opinion its not just UI changes so make sure you go through release notes to learn and then justify accordingly.
I am evaluating the option to upgrade a project developed for Alfresco 4.1 to Alfresco 5.
The project contains mostly customisations of Alfresco Share. We have new pages but also customisations of OOTB pages (the document library for example).
I know that Aikau has been already introduced in some of the pages in Alfresco 5.
I am wondering how much of our code could be reused.
Because the customisations have been implemented using Surf, most of their logic is in webscripts. Is it possible to continue to use these webscripts with Aikau?
The biggest change made in Alfresco Share was between versions 4.1 and 4.2 when all of the WebScripts were refactored to move all the logic out of the FreeMarker templates and into the JavaScript controller (see the series of blog posts starting here). The purpose of this was to make customization easier as it enabled simple configuration tweaks as well as swapping out default Alfresco widgets for 3rd party extensions. This somewhat paved the way for the approach that Aikau then follows - namely to allow all customizations to be done through the WebScript JS controller but with Aikau the widgets are much finer grained.
Ultimately it is going to entirely depend on your customizations for 4.1. The main differences you'll find are to the header bar and to the search page. The toolbar and documentlist Surf Components were also merged to reduce the vertical space that they took up.
The main issue for other WebScript customizations will be that you'll need change how you were extending them, as code that was previously in the FreeMarker template in 4.1 will now be in the JS controller.
Aikau has already been introduce in 4.2.e, to check the full listing of functionalities developed in Aikau, check this link.
Aikau is built on top of spring surf, so most of your customisations (if not all) should still be viable. The only difficulty I think you may face is migrating your project structure from the old ANT SDK,to the new one based on maven! But this page should guide you through the use of the new SDK.
I'm learning to create joomla components so is there any difference between joomla2.5 and joomla1.5 for creating components and modules as on the joomla official site documentation is about joomla1.5.
http://docs.joomla.org/Developing_a_Model-View-Controller_%28MVC%29_Component_for_Joomla!2.5_-_Part_01
You can find the tutorial of developing module in Joomla 2.5.
Yes, there are quite big differences.
First of all the install manifest has changed between 1.5 and 2.5, which means that components developed for 1.5 won't install on J2.5.
Secondly many Joomla classes has changed and some conventions are replaced by others. Check the Joomla API for the differences.
I am having much confusion over the process of upgrading version numbers in dependent plug-ins, features, and products in a fairly large eclipse workspace.
I have made API changes to java code residing in an existing plug-in and thus requires an increase of the Major part of the version identifier. This plug-in serves as a dependency to a given feature, where the feature is later included in a product. From the documentation at http://wiki.eclipse.org/Version_Numbering, I understand (for the most part) when the proper number should be increased on the containing plug-in itself.
However, how would this Major version number change on the plug-in affect dependent, "down-the-line" items (e.g., features, products)?
For example, assume we have the typical "Hello World" setup as follows:
Plug-in: com.example.helloworld, version 1.0.0
Feature: com.example.helloworld.feature, version 1.0.0
Product: com.example.helloworld.product, version 1.0.0
If I were to make an API change in the plug-in, this would require a version update to be that of 2.0.0. What would then be the version of the feature, 1.1.0? The same question can be applied for the product level as well (e.g., if the feature is 1.1.0 OR 2.0.0, what is the product version number)?
I'm sure this is quite the newbie question so I apologize for wasting anyone's time and effort. I have searched for this type of content but all I am finding is are examples showing how to develop a plug-in, feature, product, and update site for the first time. The only other content related to my search has been developing feature patches and have not touched on the versioning aspect as much as I would prefer. I am having difficulty coming into (for the first time) an Eclipse RCP / PDE environment and need to learn the proper way and / or best practices for making such versioning updates and how to best reflect this throughout other dependent projects in the workspace.
If you would like to apply the same versioning systems to feature and product, then you would set feature and product to 2.0.0 when one of the plugins go to 2.0.0. That would communicate to whoever is consuming your feature or product that there is a breaking API change inside it somewhere.
On the other hand, there is no requirement to apply the same versioning convention. You can version your bundles following that convention to properly communicate your API changes and then turn around and use more marketing-sensible versions for product/feature. Keep in mind that user will see product/feature version more than they will individual bundle version.
I've seen it done both ways effectively. There isn't really a right or wrong way on this.
... and I did the first web application using it, now I'm going to create the second.
In this first web application I enhanced the framework's core library with new things and promptly updated framework branch.
I'm using bazaar to keep framework and web application committed. The application was in the beginning, a full branch of framework source tree, now I'm updating framework manually at every change on core files. (copying changed files from web app to framework's branch).
With this second web application that I'm going to create, I need to know about versions (or revisions) which the application is based. If I found a bug in this version I can fix and then sync files with first web application no worrying: functions will be the same to this application.
If I'm going to make changes in core (new behavior, new functions in library or something new in source tree) it must be named as "new version".
What's the best way to do this?
Because I'm using a Distributed Version Control System (bazaar), I'm not dealing with VERSIONS, but revision numbers that change every time.
Please fresh my mind with new ideas.
I would organise all these apps in their own repositories:
1) Your framework code, where you then release constantly different versions: 1.0, 1.1, etc.
2) Web app 1, where you plugin your framework-component version x.y.z
3) Web app 2, where you plugin your framework-component version x.y.z
If now WebApp1 needs a new feature, you implement this in your framework-code and then you release a new version, or maybe you first collect some changes which you want then to integrate into your WebApp1 and after that you make a new framework release.
With this you can easily say WebApp1 is dependent on the framework code version 1.0 and maybe the WebApp2 is dependent on a newer framework code for example version 1.2.
Important is, that you can integrate your framework code as "component" or "plugin" to your webapps. Then you can easily replace the framework code with newer ones.
I hope I had understand your question.