I am facing a problem while scanning a SAP web UI application. Upon scanning I am receiving "there are unmapped controls".
Can someone tell me what is mapped and unmapped controls?
Thanks in advance!
Hemant,
I know unmapped controls just in the context of re-scanning. Re-scanning basically means, that you already have a module in Tosca, created earlier by you or one of your colleagues. And now you are trying to synchronize it with the application. It can't find all the controls already available in the module - those it couldn't find are marked as "unmapped". This can have several reasons:
1) you ran re-scan by accident and what you really want to do is scan
(re-scan is to update an existing module, scan is to create a new one)
2) controls have been removed from the page (then you can't map them)
3) controls have been modified (then you can map the unmapped controls to the according controls).
Sounds confusing...? Here is more on the topic.
Still confused...? Please reach out to Tricentis' support.
Michael
Related
I am new to Xamarin. I have done a couple of smaller projects (2-3 pages, one table). I have a new project that is a great candidate for a shell app. It will have 20 pages, will consume data from a transactional database (cloud hosted) but also have an offline datastore (SQLite). Right now, I just want to get the local version up and running. The template for Shell App generates an IDataService and a MockDataStore. That is a great place to start - but how do I have more than one table? I am a little confused how I would use that. What I would love to see is a template generated shell app that just adds another table (and corresponding list,detail views along with view models. For example, the simple "todo" sample but add a contact table to assign todo tasks to would be perfect. Thanks in advance for your help.
I hope this helps others new to Xamarin. When starting a new project and choosing anything other than the "blank template", the template generates a model (Item) and a services folder containing an Interface (IDataStore) and a MockDataStore. Being new to XAML in general, I spent a lot of time working on getting the UI to look like what I wanted it, learning about Shell navigation and similar topics. Finally it was time to include the data part of my project. Where I got stuck was trying to make sense of the boilerplate code. My understanding of DependencyService was for platform specific code (e.g. Android, iOS) and NOT data service dependency. Further, the templated code is a typed interface (IDataStore). The solution was fundamental - all that interface does is insure CRUD operations are available in whatever you use in a datastore. For me, simply changing IDataStore to not be typed as an Item, solved everything. It allowed me to keep the database layer abstracted away. In my little project, I completed my "MockDataStore" adding additional CRUD operations until I was ready for my real data operations. NOTE: if you generate the WEB API project from the template, it will make more sense - you can flip between your MockDataStore and actual data store.
At my new job I'm forced to use Adobe AEM and everything that comes with it.
But because everything is new to me and to my team, we are having some major dificulties understanding what are the best practices and what's the correct "code workflow". I've read everything that I could, but something's messing with my head and I just can't figure it out alone.
My question is:
When I don't want to work with the JCR tree, and I just want to make a component for a specific user (not a real CMS component, I guess), I can't understand how I'm able to reload my component information (based on some Model).
So... imagine I have an authenticated user that has N Cars.
And I've developed a component that shows the information of one of those Cars. The selected Car can change and I want to update the component with the selected Car information.
By default, when the page loads, the Car number 1 is loaded.
First question: How should this first Car be loaded?
My first try on this one was to backup my component with a WCMUse extension, and on the activate() method I would set my default Car properties.
But this seems odd to me, because I don't know how I connect this class to my Spring Controller...
I've read that ResourceModel can be used for this, but that it would map its properties to a Car JCR node that I don't have.
Second Question: Imagine that the first Car is correctly loaded and I call a method on my Spring Controller to update it.
What needs to be done to reflect this change on the Car information component?
So, to finish, I guess my main 2 problems are: What should be the model for the Sightly component, and how does the component refresh with the updated information.
Thanks a lot.
Welcome to AEM world silva, sad to listen that you are forced to work in AEM.
Though it might appear difficult initially , a developer worth his salt can gain enough expertise to work with AEM in around 6 months. For a Java developer it is difficult to relate things.
Coming back to your problem: If I understood you well you don't want to store you data in JCR and you want to hit your Spring controller to fetch the data.
Answer to First question: Ideally in AEM the data resides in JCR, it may be a User node and then Car0,Car1... CarN child nodes, here all car details are stored on car node as properties. It is all about how you want to structure your content.
If you plan not to store data in JCR you can create a OSGI service which can get the data from your spring controller and pass on to the sightly component.
Answer to Second question you can pass a parameter to your sightly component and get the relevant view of carN, Checkout Passing parameters to sightly .
You also can create href's which will load the same page and pass on some request parameter which you can read in your WCMUse (WCMUsePojo in AEM 6.2) extension activate method.
Keep learning keep helping, Cheers!
We have a requirement to allow customising our core product and adding additional fields on a per client basis e.g. People entity some client wants to record their favourite colour etc. As far as I know we can't add properties to EF at runtime as it needs classes defined at startup. Each customer has their own database but we are deploying the same solution to all customers with all additional code. We are then detecting which customer they are and running customer specific services etc.
Now the last thing I want is to be forking my project or alternatively adding all fields for all clients. This would seem likely to become a nightmare. Also more often than not the extra fields would only be required in a very limited amount of place. Maybe some reports, couple of screens etc.
I found this article from Jermey Miller http://codebetter.com/jeremymiller/2010/02/16/our-extension-properties-story/ describing how they are adding extension properties and having them go from domain to the web front end.
Has anyone else implemented anything similar using EF? How did it work out? Are there any blogs/samples that anyone has seen? I am not sure if I am searching for the right thing even if someone could tell me the generic name for what we want to do that would help. I'm guessing it is a problem that comes up for other people.
Linked question still requires some forking or implementing all possible extensions in single solution because you are still creating strongly typed extensions upfront (= you know upfront what extensions customer wants). It is not generally extensible solution. If you want generic extensible solution you must leave strongly typed world and describe extensions as data.
You will need to use some metamodel. Your entity classes will contain only properties used by all customers and navigation property to special extension entity (additional table per every extensible entity) where you will be able to put additional properties as name / value pair (you can add other columns like type, validation, etc. if needed).
This will in general moves part of your model from hardcoded scenario to configuration based scenario and your customers will even be allowed to define extensions at runtime (if you implement such feature).
I have been trying to get culture specific resources to work on an asp.net mvc 3 application.
If I have a LanguageResources.resx and a LanguageResources.en-UK.resx in my App_GlobalResources folder then I get an error "The namespace 'Resources' already contains a definition for 'LanguageResources'"
This is the end of a long line of issues that I have had with trying to get culture specific resources to work. I must say, I'm not impressed with the documentation Microsoft provide for using this feature.
I'm considering using a database table to store my culture specific strings instead, then I can just build a dictionary of all the values that will be available to my controller and views.
Has anyone else made such a decision, or have any direct knowledge on performance issues related to using a database for culture specific strings?
Has anyone else given up on resources too?
I must admit, I tried to reproduce your defect and I was successful. It looks like, Visual Studio generates additional class when you add something.en-UK.resx. Strange. It should not allow you to add anything like this in the first place for there is no such culture.
How to resolve the problem? Just add LanguageResources.en-GB.resx and delete
LanguageResources.en-GB.resx. That helps.
I would not use database for storing language-related resources, unless they are changing very frequently or must be entered by end users (i.e. there are some kind of templates).
Using the database hurts Localizability and requires much effort. It is hard to design correctly (I have seen a lot of mistakes in that area). Don't go that road unless you really have to.
We're currently migrating our ASP Intranet to .NET and we started to develop this Intranet in one ASP.NET website. This, however, raised some problems regarding Visual Studio (performance, compile-time, ...).
Because our Intranet basically exists of modules, we want to seperate our project in subprojects in Visual Studio (each module is a subproject).
This raises also some problems because the modules have references to each other.
Module X uses Module Y and vice versa... (circular dependencies).
What's the best way to develop such an Intranet?
I'll will give an example because it's difficult to explain.
We have a module to maintain our employees. Each employee has different documents (a contract, documents created by the employee, ...).
All documents inside our Intranet our maintained by a document module.
The employee-module needs to reference the document-module.
What if in the future I need to reference the employee-module in the document-module?
What's the best way to solve this?
It sounds to me like you have two problems.
First you need to break the business orientated functionality of the system down into cohesive parts; in terms of Object Orientated design there's a few principles which you should be using to guide your thinking:
Common Reuse Principle
Common Closure Principle
The idea is that things which are closely related, to the extent that 'if one needs to be changed, they all are likely to need to be changed'.
Single Responsibility Principle
Don't try to have a component do to much.
I think you also need to look at you dependency structure more closely - as soon as you start getting circular references it's probably a sign that you haven't broken the various "things" apart correctly. Maybe you need to understand the problem domain more? It's a common problem - well, not so much a problem as simply a part of designing complex systems.
Once you get this sorted out it will make the second part much easier: system architecture and design.
Luckily there's already a lot of existing material on plugins, try searching by tag, e.g:
https://stackoverflow.com/questions/tagged/plugins+.net
https://stackoverflow.com/questions/tagged/plugins+architecture
Edit:
Assets is defined in a different module than employees. But the Assets-class defines a property 'AssignedTo' which is of the type 'Employee'. I've been breaking my head how to disconnect these two
There two parts to this, and you might want to look at using both:
Using a Common Layer containing simple data structures that all parts of the system can share.
Using Interfaces.
Common Layer / POCO's
POCO stands for "Plain Old CLR Objects", the idea is that POCO's are a simple data structures that you can use for exchanging information between layers - or in your case between modules that need to remain loosely Coupled. POCO's don't contain any business logic. Treat them like you'd treat the String or DateTime types.
So rather than referencing each other, the Asset and Employee classes reference the POCO's.
The idea is to define these in a common assembly that the rest of your application / modules can reference. The assembly which defines these needs to be devoid of unwanted dependencies - which should be easy enough.
Interfaces
This is pretty much the same, but instead of referring to a concrete object (like a POCO) you refer to an interface. These interfaces would be defined in a similar fashion to the POCO's described above (common assembly, no dependencies).
You'd then use a Factory to go and load up the concrete object at runtime. This is basically Dependency Inversion.
So rather than referencing each other, the Asset and Employee classes reference the interfaces, and concrete implementations are instantiated at runtime.
This article might be of assistance for both of the options above: An Introduction to Dependency Inversion
Edit:
I've got the following method GetAsset( int assetID ); In this method, the property asset.AssignedTo (type IAssignable) is filled in. How can I assign this properly?
This depends on where the logic sits, and how you want to architect things.
If you have a Business Logic (BL) Layer - which is mainly a comprehensive Domain Model (DM) (of which both Asset and Employee were members), then it's likely Assets and Members would know about each other, and when you did a call to populate the Asset you'd probably get the appropriate Employee data as well. In this case the BL / DM is asking for the data - not isolated Asset and Member classes.
In this case your "modules" would be another layer that was built on top of the BL / DM described above.
I variation on this is that inside GetAsset() you only get asset data, and atsome point after that you get the employee data separately. No matter how loosely you couple things there is going to have to be some point at which you define the connection between Asset and Employee, even if it's just in data.
This suggests some sort of Register Pattern, a place where "connections" are defined, and anytime you deal with a type which is 'IAssignable' you know you need to check the register for any possible assignments.
I would look into creating interfaces for your plug-ins that way you will be able to add new modules, and as long as they follow the interface specifications your projects will be able to call them without explicitly knowing anything about them.
We use this to create plug-ins for our application. Each plugin in encapsulated in user control that implements a specific interface, then we add new modules whenever we want, and because they are user controls we can store the path to the control in the database, and use load control to load them, and we use the interface to manipulate them, the page that loads them doesn't need to know anything about what they do.