I am looking for the easiest way to remove attributes from every class (i.e: created / modified dates and the like) - without having to specify a customer converter on every one of our domain classes.
Additionally - I don't want to do it under normal course - but only when I enable our test case recording feature - so really I need two sets of serialization attributes, one for normal course and one for tests (hence the reason to remove the dates, because they change and I cannot determine if the results are correct).
I have not looked at the source code yet and was hoping to avoid that because I expect it will take me a while to get up to speed on it and was hoping that you could do this through the serialization settings somehow.
Thanks in advance.
Whatty
I found the answer elsewhere - it can be found at Sample ContractResolver that conditionally removes properties from JSON.
Related
To prioritize the engineering effort around Requirements in a defined way, I came to the idea to use the information already added for the FMEA.
For this I have created a Stereotype named fmeaRelevant (will be named better later), which has several Tags.
My target now is to first calculate the averages of all of these Tags and then from these the average RPN, which is again a Tag.
For this, I have already created a ConstrainedProperty, which has the respective ConstrainedParameters and Constraints.
BindingConnectors are created between the ConstrainedParameters of the ConstraintProperty and the Tags of the Stereotype.
The Stereotype is assigned to my Requirements.
However, Open ConstraintView ... does not show me anything.
Is there anything I am missing?
P.S.: I am not sure how to provide something like a source code snippet for model content. If one makes a proposal in a comment, I will add this.
You used binding connectors between stereotype properties and constraint parameters? That should not be possible, since they are on different levels. The parameters are on the model level and the stereotype properties are on the language level.
Of course, Rhapsody sometimes allows strange things, so it might well be, that there is a way to get it running.
The RPN relates to an actual hazordous situation. Your model describes this situation and all values relating to the situation should therefore be value properties of the FMEAitem. This element would be defined in a library. By the way, this is how it's done in the new RAAML-specification, which might be a useful reference.
Can anyone actually explain, in layman's terms, what is a real-world use case for the set operation's options?
While I fully understand what set with merge does, as well as merge beeing a boolean and mergeFields being an array of fieldPaths, I cannot think of cases in which mergeFields might be of any use.
I also understand the fact that mergeFields basically acts like a mask for the object passed to the set operation, but I still cannot think of how is it so useful that it actually got implemented within the SDK.
Can someone shed some light?
After looking through the documentation, there seem to be two reasons why you might want to use one vs the other:
mergeFieldPaths/mergeFields trigger an error when passing in field values that don't currently exist on the document while merge will add in those fields if they don't exist. The error is good for safety purposes if you're concerned about typos/writing to incorrect field paths.
This one is just a guess, but the documentation indicates mergeFieldPaths/mergeFields ignores AND leaves fields untouched while merge ONLY leaves other fields untouched. It's possible there's some performance advantage to using mergeFieldPaths/mergeFields esp for documents with a ton of fields. The difference might be direct access vs still needing to look at unspecified fields to identify the matches in some way.
SetOptions Reference
I have two "cq:include" in same jsp with same path and I need to make both of them editable. But currently only one of them is editable.
If I change anything in one component that shows on second. But the second one itself is not editable. My requirement is to make both the components editable while keeping the include path same.
Code:
<cq:include path ="abc" resourceType="xyz"/>
<cq:include path ="abc" resourceType="xyz"/> # This one is not editable.
Having two components with the same resource type would create only a single node at the given path. Hence, any change you make in one of the component would be reflecting in both of them, as both the components would be reading from the same node.
This is also the reason for not being able to edit the second component. Try providing different paths for different components like shown below.
<cq:include path="abc" resourceType="xyz" />
<cq:include path="abc_0" resourceType="xyz" />
Similar questions have been asked here and here
The way the authoring system works it hooks per location so if you want to have it authored in two different places those two different places should NOT be on the same page. This is just good usability as it can be very confusing.
INSTEAD, I suggest the first one on the page add an attribute to the slingRequest noting that it has been placed on the page and future instances with the same path put a message on the screen saying that it is edited elsewhere. Without knowing more details it's hard to suggest the best usability for this scenario.
Update:
If you MUST do this, here is a work around.
Step 1: define a convention for naming 2 properties. e.g. realTitle (String) and realTitleLastUpdated (date/time). These will be page-level properties, making it easy to access and check them using pageProperties. Though you can do this through a subnode as well but that gets more complicated.
Step 2: For the components that must all be simulateously editable, allow them to create their own nodes. Then, on load in the EDIT environment, check the property realTitle and the lastUpdated time stored in realTitleLastUpdated
If the last edit of your component's title, e.g. jcr:lastModified is newer than realTitleLastUpdated, change the local value of title (e.g. jcr:title) to the value of the realTitle property and update the realTitleLastUpdated time to reflect the time in jcr:lastModified on your component.
If the opposite is true - realTitleLastUpdated is of a time newer than the last modification of the local component, then update the jcr:title of the component and the times to match.
Obviously if the last update times match, do nothing.
It's a bit of a run around, but this will keep everything in sync.
I realized that you may not realize that you probably need to save the state. I believe you can do this (among other ways) using resource.getResourceResolver().adaptTo(Session.class).save()
I've done this before but it's been a while. Let me know if you have issues, I'm working from memory.
Well, if you don't want author to bother about editing both the components, then you should use javascript/jquery and onChange() of one of the component, modify the value of another component as well.
I’m curious to know how feasible it is to get away from the dependency onto the application’s internal structure when you create an automated test case. Or you may need to rewrite the test case when a developer modifies a part of the code for a bug fix, etc.
We could write several automated test cases based on the applications internal object structure, but lets assume that the object hierarchy changes after 6 months or so, how do we approach these kind of issues?
I can't speak for other testing tools but at least in QTP's case the testing tool introduces a level of abstraction over the application so that non-functional changes in the application often (but not always) have no effect on the way the testing tool identifies the object.
For example in QTP all web elements are considered to be direct children of the document so that changes in the DOM (such as additional tables) don't change the object's description.
In TestComplete, there are a couple of ways to make sure that the changed app structure does not break you tests.
You can set up the Aliases tree of the Name Mapping feature. In this case, if the app structure is changed, you need to modify the Aliases tree appropriately and your test will stay working without requirement to modify them.
You can use the Extended Find feature of the Name Mapping in order to ignore parts of the the actual object tree and search for a needed objects on deeper levels.
This is what I was forced to do after losing all my work twice due to changes on the DOM structure:
Every single time I need to work with an object, I use the Find function with the ID of the object, searching for the object on the Page object. This way, whenever the DOM gets updated, my tests still run smoothly.
The only thing that will break my tests is if the object's ID get changed, but that's not very probable to happen.
Here you can find some examples of the helper functions I use.
Background: I have a complex search form that stores the query and it's hash in a cache. Once the cache is set, I redirect to something like /searchresults/e6c86fadc7e4b7a2d068932efc9cc358 where that big long string on the end is the md5 hash of my query. I need to make a new argument for views to know what the hash is good for.
The reason for all this hastle is because my original search form is way to complex and has way to many arguments to consider putting them all into the path and expecting to do the filtering with the normal views arguments.
Now for my question. I have been reading views 2 documentation but not figuring out how to accomplish this custom argument. It doesn't seem to me like this should be as hard as it seems to me like it must be. Leaving aside any knowledge of the veiws api, it would seem that all I need is a callback function that will take the argument from the path as it's only argument and return a list of node id's to filter to.
Can anyone point me to a solution or give me some example code?
Thanks for your help! You guys are great.
PS. I am pretty sure that my design is the best I can come up with, lets don't get off my question and into cross checking my design logic if we can help it.
It's not as easy as you would like to make it.
In views, arguments are used to return objects, fx user, node, term, custom object. So you could make some custom code, to get the "query object". That would only be first step. You then need to get the info from the query object. You could either try making a custom relationship bond with the nodes or build your own filter to make the SQL needed. This can quickly become a confusing time sink.
Instead, I would suggest that you use hook_views_query_alter, which will allow you to alter the query. Since you already have the SQL, it's just a matter of checking for the hash, and if it's there, alter the query. Should be a pretty simple thing to do. Only thing that is a bit tricky, is that you have to make the query with the query object that views uses, but it's not that hard to figure out.