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.
Related
I need to customize the query widget in CRXDE (the one from Tools -> Query). Specifically I need to be able to add a new button to save queries into some sort of favorites as well as to load them.
And a second button in search result widget to export the results into a excel file.
Any idea what nodes/templates are related to each widget?
I believe this interface is not designed with overlays in mind. I'd be very cautious about extending it.
While you're still using AEM 6.1, there's a lot that has been done recently about improving the visibility of what should and what shouldn't be customized in AEM.
Furthermore, CRXDE is the kind of interface I really wouldn't like to break because of a bug in an overlay. It's just the kind of a low-level, last-resort UI that I like to be rock-solid.
CRXDE has remained relatively unchanged at least since AEM 5.6 but customising this particular interface could still cause you trouble at a later date when you need to upgrade. And if you're still using 6.1, it's likely that you'll be due for an upgrade to a newer version. 6.1 has reached end of core support and extended support is only planned until 2020
If I were you, I'd consider implementing a custom interface of your own. It might just be easier and you would be free to add further functionality without risking it breaking during an AEM upgrade.
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 have a project that has taken me 2 years, in my spare time, to develop (I am not a developer by trade) and has over 50 views. I have been told that to produce a better user experience and speed up my development I should use GwtBootstrap3. At this time I do not have time to rewrite the whole project so is it possible to include GwtBootstrap3 in the existing project, build new views using GwtBootstrap3 and slowly converting existing views to GwtBootstrap3?
Technically speaking the answer is Yes, follow setup guide of gwtbootstrap3. But, gwtbootstrap3 inject few default css in application on load which might can affect few of your current views. Hope you are following some kind of mvp patterns, if not first start use of it and then go for modifying existing views.
I am on searching special features of GWT which are present only in GWT and not in other web framework. I am a student and I am not well acquainted to the many web frameworks on the market, so if u can help me increasing my list of special GWT features, it would be a great help. Some which i know are:
1. GWT allows using java to program
web. (only, it also allows merging
javascript through JSNI of course)
2. The developer does not have to be a guru in browser incompatibilities
to develop web sites which works on
a variety of browsers because
incompatibilities are handled by GWT
through differed bindind
3. GWT allows easy integration of popular Java Tools such as ,
hibernate through gilead
4. GWT enables server implementation not only in java but also other
languages such as php
5. GWT enables code splitting which improves application interactivity
by allowing javaScript file to
download only when required
6. In essence GWT is toolkit, it does not force a way to program,
other layers can be placed on top of
it to program such as placing MVP or
MVC framework on top of GWT and then
develop app
7. GWT MVP is great because first it allows collaborative working, faster
testing with JUnit and the event bus
allows many updates in client side
application by placing event on the
event bus
8. GWT compiled java files to obfuscated mode which is first small
and make the application safer
because bots fails on the javascript
generated during the obfuscated mode
In case in the 8 points, i've mention something which not special to GWT, then let me know.
There's also 'perfect caching', which is the term used to describe the way that GWT optimises JavaScript for each browser.
Instead of building a large JavaScript file, with code that can handle all of the various browsers, GWT builds multiple JavaScript files at compile time, and downloads only the one that is relevant to the browser type that is being used.
EDIT: Every time you make a change to your Java code, GWT changes the name of the corresponding JavaScript file. Web servers can turn on caching for the JavaScript files (so that browsers won't re-download the same file), assured that the name will change when the Java code changes, and the browser will then download the latest version.
EDIT: I also really like the CssResource feature. By creating obfuscated CSS style names, GWT effectively gives each widget its own namespace for CSS styles; for example, I could define a 'pretty' style name on two different widgets, and have those styles using different CSS rules. Of course, it is possible to share CSS styles between widgets too.
Image resources are cool too. They optimise the way that images are downloaded and accessed.
Don't forget internationalization.
I think you pulled together a pretty decent list of differentiators there already. I think that one point worth adding is the RequestFactory feature in the most recent release, which, if you will, is simplistically speaking and RPC for data and makes it quite easy to develop Create, Read, Update and Delete - type (CRUD) of applications.
There are other, more important/wider accepted GUI-Frameworks that are based on Java.
There are for example Struts and JSF. That's why some of your points don't fit only for GWT, but for all GUI java frameworks in general, e.g. bullet point 1, 2 & 3.
But to add another one:
I think GWT is an easy way to code an AJAX-application, because it hides the AJAX stuff quite well. Wouldn't you agree?
Furthermore, GWT is a proprietary framework (which is somehow a unique property). JSF is standardized and Struts is lead by Apache.
I have my first GWT project that I created using UiBinder (GWT 2.0 way) which I found to be easier than write my UI creation Java source code (GWT 1.0 way).
But I saw this thing called GWT Designer that Google are releasing for free. It has nice features and wizards which were missing with the standard Google Eclipse Plugin. I like it, but I still think that using UiBinder is better. I think GWT Designer will be really useful when it can help you write UiBinder XML files (GWT 2.0 way), and not just source code (GWT 1.0 way).
What do you think about it?
Do I need to migrate to GWT Designer project?
Will it be better if I migrate but still keep UiBinder UI creation?
The latest GWT Designer now has support for UiBinder, and it works great.
http://download.instantiations.com/D2GWTDoc/continuous/latest/docs/html/wizards/gwt/uibinder_composite.html
UiBinder can give you better performance and a better optimized download than traditional widget construction; to me that's enough of a reason to stick with UiBinder. If your app is light and fast enough as it is then the choice probably comes down to what style of development suits you best.
I wouldn't go as far as to port your existing UiBinder templates into the designer. Google will be adding support for them to GWT designer soon enough.
I haven't used the newly-freed GWT Designer yet myself, but I wouldn't expect that it would warrant migrating your entire project over to it if it's already written using UIBinder.
Remember that the two methods of constructing a UI are not mutually exclusive -- you can use the GWT Designer to create a new widget and use it in an existing UIBinder project, and if you decide it's that much better, you can consider migrating at that point. Or not, since they can still happily coexist.
If you are doing professional development in an organization that utilizes experts in CSS and html, then GWt is going to be a tough sell if you don't use something like UIBinder for layouting as well as individual pages. I also think that a CSS designer can do a better job at responding to UI requirement changes than a java developer using GWT layouting techniques.
However if your java staff has control of the requirements and don't have to answer to UI designers, then I suppose choosing between delcarative templates and something like GWT Designer is just a matter preference.
As said in the relaunch announcement:
Now that these products are available again, we hope you’ll start using them within your GWT projects. Meanwhile, our next step is to more deeply unify them into the GWT family of tools by blending the fantastic Instantiations technology into the Google Plugin for Eclipse (GPE). So, there’s much more to come, including things we’re pretty sure you’ll like, such as UiBinder support in GWT Designer.
It wouldn't make sense to get ride of your UiBinder code since GWT Designer will support it soon.
DON'T use the designer plugin. The most recent update (8.1.1 at the time of this post) contains buttons that allow the user to add elements that are incompatible with IE, for instance CellTable, DeckPanel, HorizontalPanel and VerticalPanel.
This means whoever uses the plugin, uses it entirely at their peril. If IE7 tries to pull in these elements, it will load a partial page but fail to load components that use these elements. IE8 may not be able to load the application at all.