I am in the process of converting the deprecated methods & classes of WFFM from 8.0 rev.150429 (Update-3) to 8.1 rev. 151008 (Initial release). Sitecore provided a good documentation > release notes for the 'breaking changes' that would occur when converted to WFFM 8.1.
Link to release note:
https://dev.sitecore.net/Downloads/Web%20Forms%20For%20Marketers/Web%20Forms%20For%20Marketers%2081/Web%20Forms%20For%20Marketers%2081%20Initial%20Version/Release%20Notes
And that includes moving some classes from Sitecore.Form.Core.dll to Sitecore.WFFM.Abstractions.Actions.dll (okay I understand).
However, though I am not really sure, maybe I just couldn't locate the right page/site, but there were also some changes made in the Sitecore.Forms.MVC 8.0 to 8.1 which were not documented. To be specific, classes are as follows:
Sitecore.Forms.MVC.Models.FieldModel (removed in Sitecore.Forms.MVC 8.1)
Sitecore.Forms.MVC.Models.SectionModel (removed in Sitecore.Forms.MVC 8.1)
Maybe there were also other classes that were removed, as well. But I am only concerned about the above two (2) classes for the mean time.
So, I'd like to know if someone already ran into this scenario before when upgrading WFFM to 8.1 and how you were able to resolved the issue?
I have a hint that I just have to look for the NEW DLL that uses or implements the FieldModel and SectionModel, but again, I couldn't find it as of this writing.
Appreciate any help. Thanks.
There is no FieldModel and SectionModel anymore, but I assume you are looking for the FieldViewModel and SectionViewModel. They can be found still in Sitecore.Forms.Mvc in the Sitecore.Forms.Mvc.ViewModels namespace.
If you need more specific classes, you can check the Sitecore.Forms.Mvc.ViewModels.Fields as well - or open the Sitecore.Forms.Mvc dll with a decompiler (as I did).
Related
I'm working on a semantic-web project and I'm looking for real-life ontologies to test a couple of applications an algorithms. What I'm searching for are different sizes and structures, something that will allow me to benchmark the company's solutions, preferably, not home-made mocks, but something that is actually used. Unfortunately, looking at the entire ontology using OntoGraf is a little cumbersome.
I found a Protégé plugin called NavigOwl, which seems to be perfect for the task of viewing an entire ontology at once and judging its general complication and structure. The thing is, I can't get it to work.
I download the plugin from HERE and follow the instructions.
I put the jar in the plugin directory of my Protégé install.
I open protege and load an ontology
I go to Window>Tabs and select NavigOwl
A NavigOwl tab appears but it only contains the class hierarchy view, while the rest of the window is grey. It's simply blank, as shown below:
Clicking any of the classes in the hierarchy view does not change anything.
I googled for a solution and I managed to find this thread on nabble.com. The poster says he fixed the problem but he doesn't know how. Resetting the tab to default state is among the implied solutions but it doesn't work for me. Closing and reopening the tab, as well as Protégé itself changes nothing.
Have you encountered the problem? What could be the cause?
I'm using Protégé 4.1.0 Build 239 with the bundled JRE (1.5.0) on Windows 7 home premium x64.
I've tried both the JAR available here (NavigOwl plugin for Protégé 4.1) and the one mentioned in Protégé wiki at Stanford, here (version 1.1.0) but the situation persists.
I had came across the same problem but when i upgraded the JDK it started working. though i do not propose upgrading was the solution but it is working now.
It is this sad moment to a developer's life that he has to maintain and fix legacy code... In my case I have to deal with a modified (core scripts) tinyMCE 3.2.2 which I have to update to the latest version in order to play in IE9+...
So my question is if there is a way to check which files have been changed since version 3.2.2 and try to update only those cause it is an overkill to check all the code for the modifications...
Thanks in advance
I fear there are so many changes in so many files that most of them have changed since then and in order to work with IE9.
If possible you should never ever modify the core code. Instead use custom plugins if possible.
I inherited a small Microsoft Enterprise Library project that supposedly worked a couple of months ago. From what I can tell, it has code that was lifted directly from the Enterprise Library source (?!) instead of linking the built DLLs.
Sigh.
So, there are classes that don't compile in the Microsoft.Practices.ENterpriseLibrary.* namespaces. There's a reference to a cryptic LOGNS namespace which has a static LogHelper class with a bunch of Log* methods.
I can't figure anything out about this class, other than that it's missing (and trivial to stub out), but I'm concerned that I may be missing some references (in my GAC?) or something.
This is one trivial error out of several; I have a feeling this code did work (since it's ten projects in a solution), and only that I'm missing something locally.
But what?
There's no such namespace or class in Enterprise Library. Sounds like you didn't get all the source code.
Well, no current versions - any idea what version of Entlib you're dealing with?
I have gone through this post and the links, and still can't solve my issue.
I have changed my config to name the assembly, but it makes no odds.
We recently moved the projects and think that might be an issue - but how to solve it if so. I don't quite understand how EF when running finds the cdsl etc. files I thought they were embedded in the dll [it is set to do so]?
The service having the issue doesn't directly use EF itself, it uses another DLL which DOES. I also added a direct ref to the DLL but no joy.
Also, the same code (the dll that contains the functionality, not the wrapper service) using the same connections strings works fine in my system test project via the IDE.
Turned out to be down to incorrect initialisation of StructureMap and not really to do with EF itself.
Simple usecase: assemble an Eclipse product using simple scripts, just dumping bundles into the plugins dir.
This used to work with 3.3 - with 3.5 it's broken: my application doesn't start as the app plugin is not found.
Question: what's the easiest way to fix that? This seems to be the only pain in the whole upgrade process for me.
Attempts:
I guess this is a no-no for P2: it maintains the bundles.info file instead, which is probably very smart.. a bit too smart for me.
Some ideas I had:
can I just skip P2 altogether and get back to plain old, simple -dirty- discovery mechanism?
can I set up plugins dir as a 'watched directory'
looks like I need to use the p2.reconciler for that.. oh wait, it's deprecated already :-( bug 251561.. (thanks VonC for the pointer)
can this old setting in the config.ini still work? (which is now replaced with the 'simpleconfigurator') osgi.bundles=org.eclipse.equinox.common#2:start, org.eclipse.update.configurator#3:start, org.eclipse.core.runtime#start
should I call the (p2) director?
"please pick my plugins up" :)
I'd avoid the dropin folder for this - that's more for the
end-users.
I'd avoid messing with the bundles.info if possible.
I don't care about all those smart features in my product yet- actually the users don't use the built-in update mechanism at all.
So I'd like to KISS (ie: just to start up), and add more advanced support when needed.
I've asked this on Eclipse forums, but no answer yet, so would really be grateful for some enlightenment.
Also, feel free to correct me on the assumptions - I've just read the P2 docs, which seem confusing at times.
Thanks!
Answer: actually option 3 above seems to work after all - thanks Francis for confirming this! (it didn't work originally, but that was probably caused by some missing deps).
My only issue with that now is, some Eclipse bundles actually require simpleconfigurator. So I wonder if swapping it out will cause problems down the line.
You can alter your configuration/config.ini file to not use the org.eclipse.equinox.simpleconfigurator (which does the p2-based configuration) and instead use the org.eclipse.update.configurator which is the old-school way of just configuring whatever is in the plugins directory. This should give you what you want.
Even if it does not fully answer what you are after, you can specify in an eclipse.ini (like the one I describe here):
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=C:/jv/eclipse/mydropins
That does specify to p2 to monitor any directory of your choosing to detect plugins in it.
Another source of idea could be this article: Composing and updating custom Eclipse distros
It's not hard to create a feature based product that includes these things, and do a product build to end up with something like this:
Note: the concept of reconciliation is detailed in the eclipse Wiki.
For certain installations of Eclipse, there will exist the notion of a shared installation -- this may be in the case of a Linux system where a base set of software is installed via packages (perhaps RPMs), or may be in a Maya deployment where shared profiles are defined in a central server.
In both cases, it is necessary to perform reconciliation between the shared profile and the user's current instantiation of the profile including any modifications they may have made.
Part of this mechanism is the Dropins Reconciler setting. Although, as bug 251561 illustrates, it is not advised to put too many plugins in there.
Maybe this will help you (shot in the dark)? I found this when upgrading my Eclipse installation to Galileo and trying to keep my Flex Plugin install.