I have a View Object which need to be refactored and moved to another package.
Will refactoring the VO also make the necessary changes to its VOImpl class and SDO files?
Yes, all the parts of the VO definition are moved. Notice the "+" sign to the left of the VO name. If you click this it expands and shows all the files that make up the VO definition.
When you move an object via refactoring all the files contained in the object are moved and all references to it anywhere in the model are made. This post has some details that might be useful -but note the date as you do not mention your ADF version. Always indicate the version when asking questions here.
Also the docs.
Related
Stuck at a trivial problem in Grails 3.1.5: Show the fields of a domain object, excluding one of them, including a transient property. Yes, this is my first Grails 3 project after many years with previous versions.
The generated show.gsp contains
<f:display bean="rfaPdffile"/>
This will include a field that may contain megabytes of XML. It should never be shown interactively. The display: false constraint is no longer in the docs, and seems to be silenty ignored.
Next I tried explicitly naming the fields:
<f:with bean="rfaPdffile">
<f:display property='fileName'/>
<f:display property='pageCount'/>
...
</f:with>
This version suprisingly displays the values without any markup whatsoever. Changing display to field,
<f:with bean="rfaPdffile">
<f:field property='fileName'/>
<f:field property='pageCount'/>
...
</f:with>
sort of works, but shows editable values. So does f:all.
In addition I tried adding other attributes to f:display: properties (like in f:table), except (like in f:all). I note in passing that those two attributes have different syntax for similar purposes.
In the Field plugin docs my use case is explicitly mentioned as a design goal. I must have missed something obvious.
My aim is to quickly throw together a prototype gui, postponing the details until later. Clues are greatly appreciated
If I understood you correctly, you want to have all bean properties included in the gsp but the one with the "megabytes of XML" should not be displayed to the user?
If that is the case you can do:
f:with bean="beanName"
f:field property="firstPropertyName"
f:field property="secondPropertyName"
And the one you don't wish to display:
g:hiddenField name="propertyName" value="${beanName.propertyName?}"
f:with
So list all the properties as f:field or f:display and put the one you don't wish to display in a g:hiddenField Grails tag
You can also try:
f:field property="propertyName"
widget-hidden="true"
but the Label is not hidden in this case.
Hope it helps
My own answer: "use the force, read the source". The f:display tag has two rather obvious bugs. I will submit a pull request as soon as I can.
Bugs aside, the documentation does not mention that the plugin may pick up the "scaffold" static property from the domain, if it has one. Its value should be a map. Its "exclude" key may define a list of property names (List of String) to be excluded. This probably works already for the "f:all" tag; bug correction is needed for the "f:display" tag.
My subjective impression is that the fields plugin is in a tight spot. It is intertwined with the Grails architecture, making it sensitive to changes in Grails internals. It is also required by the standard scaffolding plugin, making it very visible. Thus it needs constant attention from maintainers, a position not to be envied. Even now conventions for default constraints seem to have changed somewhere between Grails 3.0.9 and 3.1.7.
Performance of the fields plugin is sensitive to the total number of plugins in the app where it is used. It searches all plugins dynamically for templates.
For the wish list I would prefer stricter tag naming. The main tags should be verbs. There are two main actions, show and edit. For each action there are two main variants, single bean or multiple beans.
My answer is that at present (2 March 2017) there is no answer. I have searched the Net high and low. For the index (list) and create and edit views, the fields plugin works well enough. A certain field can be easily excluded from the create and edit views, relatively easily from the list view (by listing those that should show), and in no way I could find from the show view. This is such a common need that one would suspect it will be addressed soon. Also, easily showing derived values in the show view, like 'total' for an invoice. One can do that by adding an ordered list with a list item showing the value below the generated ordered list of values, but that is kind of a hack.
In some ways, the old way was easier. Yes, it generated long views, but they were generated and didn't have to be done by the programmer - just custom touches here and there.
In ClearCase GUI, when I tried to check-in, an empty comment field will be shown, which I can fill in check-in messages.
Is it possible to set template for this message?
For example, when the team need to checkin, below message will be shown, and each team member can just fill in the commit message.
Reviewer:
Test suggestion:
Thanks
There is no native template mechanism that I know of.
You can try and see if the ClearCase environment variables could help, like setting in a pre-op checkin trigger a:
CLEARCASE_CMNT_PN
The path name of the file in which cleartool and multitool cache the most recent user-supplied comment. Defining or removing this EV enables or disables comment caching.
(and make sure that file contains a message template)
That thread from 2005 though mentions:
The CLEARCASE_* environment variables are effectively read only (changes to them have no effect.)
Some potential options are:
A) reject comments that do not meet your template and make the user fix them and redo the checkin/out
B) put a wrapper around checkout/in operations to meet your template needs
C) use 'ct chevent' to change the comment during a postop trigger
D) use attributes, hlinks, or labels to store the information instead of using the comment field. (You can apply the attributes, hlinks, or labels during the preop)
I'm thinking that C or D might be your better choices.
I'm having fun with a change to a content type field (from a node reference to a text field) which results in an error when a recreated feature is merged. The error is
FieldException: Cannot change an existing field's type. in field_update_field() (line 234 of /var/www/htdocs/modulesfieldfield.crud.inc)
At the moment, this is only affecting a merge back into a developer's workspace and the staging environment is a clean build from GIT, so unaffected. But it raises an early flag in terms of defining an update process when it goes to production.
When in production, I assume that it will be a matter of managing an export of each instance of that content type, remove the content type, install the recreated feature, migrate the exported data into the refactored content type and then apply any tests that may be defined for that change.
What is the recommended best practice process, i.e. the standard to follow to get it right at the outset?
Many thanks in advance
Best way is to tag your feature with a version.
First version: your old field and it's data
Second version: your old field definition and the new one.
In this version you can migrate the data contained in the old field within a hook_update_N().
Third version: simply remove old field definition
I hope to have answered your question as you expected
How to use treeview e. g. as sidebar?
There are no standard element. You can build your own View. Look in other projects for some implementation or use jsTree
It seems there is an add on that is exactly for what you are looking for listed on the website.
At least it seems that way according to the description.
Its located under development and add-ons.
I'm thinking about trying the framework myself so I have no idea if this will work for you or not.
I noted there is a file atk4/lib/TreeView.php which extends Lister
It appears to be a bit old as it has hardcoded paths to the icon images for + and - as amodules3/templates/kt2/ which in agiletoolkit 4.1.1 is /atk4/templates/shared/images but maybe you can try adding this to a page and see what it does.
From the comments at the top, looks like it needed a mysql table with a primary key called ID and another column in the same table called parent_id which would provide the values and probably in order to display text strings would probably need another column called name in the same way refModel works.
If you decide to try and get it working, maybe you can post it back to Romans to update in ATK4.1
Please check newest ATK4 addons source:
* https://github.com/atk4/atk4-addons
* * addon "hierarchy"
* * addon "tree"
In a ClearCase config spec, is it possible to select versions based on element attributres (not version attributes)? For instance:
element * ...{SOME_ELEM_ATTR==SOME_VALUE&&lbtype(MY_LABEL1)}
This doesn't work because the last part of the "element" spec is a version-selector, which only looks at version attributes.
What I'm trying to do is partition my files into two or more classes, and have different "element" lines apply to different classes of files. I tried tagging all the elements in one class with an attribute, but hit a dead end with trying to base the selection on that in the config spec. The only way I can see to do this sort of thing is to put all the files of one class in one place and use the second construct (the "pattern") to differentiate:
element .../all_class1_files/... MY_LABEL1
but this is really ugly because you have to move all the files of one class into one place, or have a giantic config spec listing all the individual directories and/or files.
Thanks in advance...
Ray
One first solution would be to replace the attribute criteria by a branch.
That way, you would more easily be able to label all files from one branch or another, instead of "all files with a given attribute".
Other than this workaround, you will find some find command based on attribute here (or in the man page).
You could then combine a find query with an "-exec" directive to put the label that you want.
That way, you don't have to mess with the config spec syntax (which may not support the exact selection criteria you are after).
I didn't test it, but you could try
element * ...{SOME_ELEM_ATTR==SOME_VALUE && lbtype_sub(MY_LABEL1)}
, because lbtype_sub is an element, branch and version selector (whereas lbtype is just a version selector).
However, since lbtype doesn't seem to be part of the config spec criteria, I doubt it can work in said config spec.
I think I've up with a good solution using "trtype" as a selection criterion (appears to be the only query function that inherits from the element to the version). If the Class1 and Class2 elements have dummy triggers Class1Files andClass2Files attached to them, respectively, then something like
element * .../{trtype(Class1Files)&&lbtype(MY_LABEL1)}
element * .../{trtype(Class2Files)&&lbtype(MY_LABEL2)}
should do the trick. This selects files in Class1 with MY_LABEL1 and in Class2 with MY_LABEL2. I haven't actually tried this out yet, but I'll let you know how this works out.