In Hybris version 2005, com.hybris.backoffice.widgets.notificationarea.NotificationService seems to be deprecated
https://help.sap.com/doc/a6c03b79dbfa4fc485848de0711cc149/2005/en-US/backofficeframework/com/hybris/backoffice/widgets/notificationarea/DefaultNotificationService.html
They are suggesting using com.hybris.cockpitng.util.notifications.NotificationService instead
https://help.sap.com/doc/a6c03b79dbfa4fc485848de0711cc149/2005/en-US/backofficeframework/com/hybris/cockpitng/util/notifications/NotificationService.html
But from what I can see from the OOTB code com.hybris.cockpitng.util.notifications.NotificationService is just extending from the old one com.hybris.backoffice.widgets.notificationarea.NotificationService which is deprecated and there are no new methods introduced,
so even when using this new NotificationService, when I call notificationService#notifyUser i still get a warning saying that the method notifyUser is deprecated.
Is this normal, or am I missing something?
If it is what SAP is recommending, it should be fine. SAP will probably update it in the future. There is no problem using deprecated methods, as long as they are still available. However, you might want to update in the future, in case there are major improvements in the new replacements, versus the old one.
Related
I had liferay 7.0, when you open the ispect ( Ctrl + Shift + I) then go to the console and write
for english
Liferay.Language.get('login');
"Login"
german language
Liferay.Language.get('login');
"Anmelden"
But Now when I upgraded to Liferay 7.4 , I get
for english
Liferay.Language.get('login');
"login"
german language
Liferay.Language.get('login')
"login"
The issue has been reported
https://issues.liferay.com/browse/LPS-123191?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
https://help.liferay.com/hc/en-us/articles/4403607020813-Liferay-Language-get-method-is-no-longer-working-with-string-variables-as-of-DXP-7-3
From one of the comments in the tickets that you've linked yourself:
That option was deprecated under LPS-113569 and is no longer available. You can get some extra information in the pull request deprecating such functionality:
Liferay.Language.get is replaced by the language filter and we also want to remove the AUI dependency, so in this change, we migrate the Liferay.Language.get function to frontend-js-web.
Note that the migrated version is dumbed down to just return the key: it does not preserve the dubious fallback behavior of the old implementation, that used a deprecated synchronous request to the server to fetch the value, which would produce a console warning, and very likely end up returning the key anyway (unless the corresponding value happened to be in the kernel); in short, the old implementation only wallpapered over a real problem (failure of the filter to do its actual job).
One of the linked issues is about updating the documentation, which hasn't happened yet.
Edit, following your comment:
The documentation that you link in your comment looks like the not-yet-updated documentation.
In general, I've confirmed your statement (which wasn't a question, by the way): Indeed, the feature you've been using has become less and less useful (as it was only good for a few translations from core, never from any module, and retrieved them in a performance-killing way. It's not possible to extend it to retrieve all modules' keys and do so in a performant manner, so you should use whatever technique the libraries you're using to translate your frontend are using)
In case you're building your UI with JSPs, that would be <liferay-ui:message key="your-key-of-choice"/>. In other cases, you know what you're using, and that framework definitely has means of providing localization.
yes, this is true it does not work anymore, as Olaf Kock said , you need to implement a new way to localize javascript , there is a npm tool for this #clavis/translation-transformer
We have a complex scenario which requires a timer job to run after content deployment to a SP 2010 site collection. The timer job automatically deactivates/reactivates a branding feature which is responsible for setting the master page for the site collection, among other things.
We have had several feature upgrades along the way, and neglected to call .Update() on the feature in that specific site collection. So all of the updated CSS, master page, page layouts etc. are out of date on that SC.
The strange part is that when I checked the version number of that feature in this SC, it shows as the latest version. The custom upgrade action clearly didn't run and update the files, because nobody called .Upgrade().
One of my colleagues suggested that the deactivate/reactivate process done by the timer job would update the version number, meaning that I can no longer call Upgrade()!
Is that true? Does a deactivate/reactivate cycle for a feature automatically update the feature version number?
Is there an easy way to fix this mess? Some way to decrement the version number programmatically, then call Upgrade()??
On 1: No. Feature deactivating / activating does not trigger an update. See this article by Chris O' Brian: http://www.sharepointnutsandbolts.com/2010/06/feature-upgrade-part-1-fundamentals.html
Feature upgrade does NOT happen automatically (including when the
Feature is deactivated/reactivated)! The only way to upgrade a Feature
is to call SPFeature.Upgrade(), typically in conjunction with one of
the QueryFeatures() methods. My tool which I’ll go on to talk about is
a custom application page which helps you with this part – note there
is no STSADM command, PowerShell cmdlet or user interface to do this
out-of-the-box.
Is your timer job cycling the feature activation with Force? Then, yes, it is triggering the feature upgrade/feature update see the following screenshot from SPFeature.Activate (see my yellow marking):
Why the feature version is incremented, I'm not sure. When you have a feature, install a new feature version and activate / deactivate, the feature version stays the same unless you run an Upgrade, see also this related question stating the same: https://sharepoint.stackexchange.com/questions/41476/feature-upgrading-question
I'm guessing your timer job is using force? Otherwise I'm not quite sure what is happening.
On 2: Don't know if it is possible to decrease the version number, but the safest way would be to just create a new version including a grand "clean up" feature receiver which sets everything correct, i.e. checks which steps of the feature upgrade have happened already (e.g. new list created, new content type added) and which haven't. Depending on that just execute the same steps again which have not executed yet. For the latter part you can fortunately use the existing code, so you would only need the "clean up" or checking code.
After some testing I found that simply deactivating and reactivating the feature will increment the version number and completely screw up your upgrade! I even watched the update come through in the content database. As soon as you deactivate/reactivate the updated feature, the new version number pops into the content DB. Of course the upgrade doesn't actually run, it just increments the version number.
This means that if you then call .Upgrade() it won't work because SharePoint thinks it's already been upgraded!!
To fix this I updated the row in the content database to set the feature version back to 0.0.0.0 for that particular web and then I could run .Upgrade() just fine....but that's not exactly a supported solution. If anyone else has a better idea drop a reply.
I am working through the pluralsight videos on MonoTouch. At one point, the trainer right clicks on the name of a derived class, and in the 'refactor' menu there is a function to override/implement members of that class. When I click however (latest version), I see only 'rename.'
The person in this link had the same issue some time ago and has included screenshots - but noone replied to them in the MonoTouch discussion group:
http://monotouch.2284126.n4.nabble.com/Right-Click-Class-name-gt-Refactor-gt-Override-Implement-members-tt4655504.html#none
Has anyone experienced (and resolved!) this?
Some of the refactoring features were reorganized or removed (for now) in the rewrite of the code code completion engine that took place for MD 3.0.
You can still access this particular feature two ways:
1) After typing the "override" keyword, MD offers the members you can override/implement. Selecting one will cause it to be stubbed out.
2) You can override many members at once using the "Edit->Show Code Generation Window" command in the class body. This command doesn't have a keybinding on Mac by default, but you can assign one in Preferences.
MonoDevelop 3.0 (and later) removed some features (including a few about refactoring) since they were not as stable, fully functional (complete) or buggy.
The same features (or similar ones) are likely to come back in future releases.
I have an XSD that's going through a transition from one set of elements to another. During the transition, there'll be code expecting the new elements and code expecting the old elements. Therefore I need to keep the old elements in the XSD; I'm documenting them as deprecated (using free text in an xs:documentation element).
Is there a way of marking an element as deprecated such that a tool like xmllint will automatically warn if someone uses a deprecated element?
Create a new schema, with a new namespace. Call this "version 2". If you choose to support version 1 XSD and version 2 XSD in your application that's fine, but keep them seperate and don't try to layer the two on top of each other - especially if you're going try to stop people from using the version 1.
This is worth looking at as it describes some of what you're dealing with:
archive of http://www.pluralsight.com/community/blogs/tewald/archive/2006/04/19/22111.aspx
I realise, however, that doesn't really address your question. With regard to "is there a way to do this?" the answer is "no - not in a universally supported manner". I've seen people add their own doc annotations to give hints, but this isn't going to be universally understood by tooling.
Your best bet in the long run is to create come up with a versioning story for your schema(s) and keep version 2 seperate from version 1.
Is it possible to mix them? I'm asking because I have a big project that uses Subsonic 2.x generated classes (in a compiled dll) but would like to start using 3.x for new stuff.
I tried it last night with a project where I had references to both subsonic.dll and subsonic.core.dll but that didn't work with ambiguous references, etc. So removed 2.x and then got an issue with my older compiled subsonic generated classes in that they needed Subsonic 2.1 to run.
Hmm... I think there's a small chance that you might be able to do this, but you'd need to use the full qualifying class names (namespace.class) for a lot of code because there might be naming conflicts. It wouldn't be easy to do and definitely not recommended. (It might not can even be done.)
You can't move from 2.x to 3.x without doing a lot of recoding. I have a bunch of big projects in 2.2 and after trying to update to 3.0, I ran into some issues so I've decided to keep them in 2.2. I'd love to upgrade to 3.0 and use the new stuff, too, but I don't have the time (right now) to recode the stuff that changed between 2.x and 3.0.
I do recommend updating to 2.2. There shouldn't be any backwards compatibility issues between 2.1 and 2.2. I was able to update to 2.2 by just changing out my reference.
Just curious, are you using ActiveRecord or Repo implementation?
You only have 2 options:
stay in 2.1/2.2
update your code to 3.0
Thought I'd follow up here and let people know that I was able to get this to work. What i chose to do was to edit the Subsonic 2 source code and put it into a Subsonic2 namespace (everything), recompile to subsonic2.dll, etc. Had to modify the web.config slightly, then went and modified my old code to reference subsonic2, etc.
Am now able to mix both Subsonic 2 and 3 in the same project.
Gerry
Jim--I'm using ActiveRecord. The 2.x is in one namespace and 3.x would be in another. However, I guess the question is whether the 2.x can be compiled to run with the 3.x runtime.
Thanks,
Gerry