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.
Related
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.
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.
I am facing a common issue that most of us face while writing UI automation tests:
Strong coupling of automation tests with the AUT. If an enhancement changes UI of a module, you have to go and spend a lot of time changing:
1. Either the code (logic) to test the module.
2. Or just the locator of an element.
If the change in UI is minimum, it's ok to manually replace the locators in the test. But it is not possible to do this if the change is very large considering deadlines and time constraints.
I am trying to figure out a way to implement a tool / utility that will save my time from changing locators of any element in the web-app that I have stored in my locator map.
For example:
I have a locator for a search result list in my locator-map as:
searchResultsLocator=span[id="searchResults"] > ul > li[class="ui-menu-item"] > a
If a dev changes this by replacing the span with a div as a part of some patch, then I want this to get automatically get updated in my locator-map.
Has anybody worked on this problem? Can someone suggest something?
I am not sure if the problem is fixed or not, if not fixed you can try this..
I face the same issue is well but no more.
Create a file where you keep all the element references (if no ID is present you can use XPath) and then use a variable which takes value from this file instead of hardcoding it.
Do not create a single file for entire application, make sure you have related elements in a single file (say element of single page).
So when the UI changes you will have only one place to edit instead of entire test code.
You can use multiple/backup locators for each element. See my question here: Pros/cons for using multiple locators per element in Selenium?
This doesn't automatically update your locators for you, but I was afraid attempting to do so might update them incorrectly. And then you might end up with a kind of false positives - tests which pass because they auto-updated to new locators, but locators for the wrong elements!
However, pre-defining multiple locators allows your test to continue running smoothly when one locator fails, but you can generate reporting/notification about the failure, and then still have time to do your manual updating of locators, as long as at least one of those backups continues working.
Is there a list somewhere that lays out all of the types of changes that can be made to an existing workflow service that would prevent existing instances of the original workflow from being re-loaded? For example, I recently made a small change to a custom activity (changed a condition in an "if" statement) and all existing workflow instances still load as normal. Now, in the past, I had removed a property on an object that the workflow uses, and when I tried to re-load a persisted workflow instance, it blew up on me.
Does such a list exist? Thanks!
As far as I am aware there isn't a list like that. You really should consider all changes as breaking. If you test thoroughly you will find a few exceptions but these will be mostly changing a single VB expression.
There is no such a list.
As far as I am concerned, you can change VB expressions always editing the .xamlx in a text editor. I say that, because in my case, sometimes the graphical editor (VS2010) changed the ids of the activities without introducing new activities (be carefull with this).
You can also change the whole internal code (not the inputs/outputs parameters) in code activities (.xaml). Because of that, it would be a good idea to put all the "high changeable" logic into code activities in order to be able to modify this logic avoiding problems with existing WF instances.
I have a Drupal 6 website with about 20 pages. Inside every page, I need to create a lot of widgets with information either stored inside the database or from external web services. Most of the time, a "view" (from the view module) is just not enough to solve the requirement.
Up until now, any time I need such a widget, I create a new module which implements hook_block. Then, I drag and drop this new module inside the panel I want. I will need to create about 20 modules. This works pretty good. However, I'm not sure if this is the correct-drupal-strategy and I would love to receive some feedback from experienced Drupal developers.
A module can expose as many blocks as you want (in theory, admin/build/blocks will teach you otherwise ;)).
Have a look at the documentation of hook_block(), you just need to extend yours to return multiple block infos and then decided which one to show based on the $delta.
So you don't need 20 separate modules, maybe 2-3 and group the blocks somehow together because just a single module might be hard to maintain. The thing is that every single module makes your site a tiny bit slower (at least one more file to load, module_implements() needs to loop over every module for every hook and so on).
Without more information , it's hard to give any better advice. Maybe you could expose your data to views, or write a views plugin to display it in the way you want it, or...
Although Berdir's answer is pretty good, I'm impressed there's no link to any documentation in it. hook_block is meant for several blocks, and they can share functions that build their content. The API page is good, the example it gives defines two blocks at once.
You should notice each defined block has a delta (a key in the $blocks array). You can have dynamic deltas and use values in it to fetch data (passing a nid or uid and getting related content, for example).