I'm working on a small team of around 10 developers, all using Rhapsody. We've recently noticed source artifacts in some of our classes, which aren't visible in the browser by default. They usually only change the ordering in generated sources, but some override changes to the model. In some cases we've lost time debugging new changes that didn't seem to work, only to discover the changes were being replaced by an implementation in the source artifacts.
Is there a way to disable or avoid generating source artifacts in Rhapsody?
I've seen them generated when saving with the active code view focused, but there may be other ways our team is inadvertently creating them. I checked SO to see if anyone else had a similar issue, and IBM's documentation didn't mention anything about disabling them or what actions implicitly create them. We're using Rhapsody 8.1.2.
The Source Artifacts in Rhapsody are created to preserve data from the code which is not mapped to UML model element. Such as ordering as you have mentioned, and more.
In case that you do all your changes from model, and not from code, you can disable the update of the model from code. In the Code menu, select Dynamic Model Code Associativity and then Code Generation. So Roundtrip will not run and update your model with changes from the code. Unless you run it manually from menu.
In case that you do want to update the model with changes from code, but less then the default. You can change the Roundtrip scheme from Respect to Advanced. This will allow you to add/change code elements in the code, but not to; change order, add global comments or pre-processor directives.
There is also Basic scheme which allow you to only modify functions body.
See the property [C/Cpp]_Roundtrip::General::RoundtripScheme
Related
I have been building small "proof of principle" programs to learn about GTK3, and now that GTK4 has limited availability, I have been attempting to learn about this version as well. In attempting to migrate to GTK4, I took a program I wrote for GTK3 that displays two progress bars with different attributes using CSS providers and rebuilt it under GTK4. When I ran the GTK4 version of the program, the CSS overrides in the program are ignored unless I introduce the CSS provider context to the display level for one of the progress bars. But that then results in having both progress bars exhibiting the same behavior instead of having unique behavior for each progress bar. Just as a further test, I added CSS providers and context for a label widget and that override worked. So some CSS overrides in GTK4 work as before, but some do not. It is as though some CSS provider overrides are ignored at the display level. Reviewing documentation about priorities (e.g. GTK_STYLE_PROVIDER_PRIORITY_APPLICATION) and testing out various priority constants did not make a difference.
Displaying the content of the code would be too long in this narrative, so I have uploaded the GTK3 and GTK4 versions of the code to my Github repositories along with a "pdf" file visually illustrating the different behavior between GTK3 and GTK4. If you want to review and test out the code yourself, the link is:
https://github.com/cschuls/GTK4_Mystery
I would suppose that widget-specific CSS customization could be added at the display level with an "id#" attribute, but that seems like that would just be adding unnecessary complexity when this practice works fine with GTK3. Thanks in advance for any answers and suggestions.
Additional comment.
Experimenting with various scenarios, I came up with a work-around that provides the desired result of having distinct style properties applied to each progress bar widget. For those widgets, I added their respective CSS provider data to the display style context instead of attempting to add the CSS provider to each widget's context. If you wish to view this work-around, I added a "work-around" folder with the source code to my Github repository.
This provides a decent solution to this problem, but it does not answer my underlying question as to why the CSS provider information for each progress bar widget is not enacted upon during the application's execution; whereas, CSS provider information associated with widgets such as labels and buttons do behave as they did with GTK3. If anyone can answer my core question, I would be very happy.
Regards,
Craig
Have anyone tried to have a form with MultiValueField in Magnolia having Composite fields with i18n enabled and is working properly?
Currently, I'm encountering some weird behaviour when adding items to English then switching to other language and adding items again then switch back to English with items all gone. In one JIRA post it said it was already fixed but I still encounter this issue. Also encountered issues in sorting which apparently not supported by the DelegatingMultiValueTransformer.
If so, can you please show me the configuration you use to make this work properly? If needed customisation, can you give me ideas on how to do it?
Would really appreciate any help on this.
Btw, I'm using the latest release 5.4.6 now.
Maybe you don't want to put two questions in one request in the future ;)
Re language issue:
did you check that you have i18n enabled also on the subfields, since you are using deletage transformer? AFAIK with delegate you need to have them enabled on all fields in the hierarchy.
Re transformer & ordering:
IMO the only way out is to write custom transformer. Look at source code of MultiValueTransformer and in the part of the code where it goes just two levels down when checking child values, you need to go deeper.
You would also need to define different structure storage for your values there since one used by the MultiValueTransformer would not suffice for multiple levels.
Perhaps you can extend one of the more specialized MultiValue*Transformer or perhaps you try MultiValueJSONTransformer if storing all values in json array is enough for you (you would still need to extend it and to repopulate values back into dialog when opening dialog for editing).
HTH,
Jan
Alfresco offers both dynamic and static deployment of custom content model [1]. However, it is still not very clear to me why would one renounce to the dynamic deploy advantages.
When should one go with bootstrap deployment? What are functional differences between the two?
[1] http://docs.alfresco.com/5.0/concepts/content-model-deploy.html
Both approaches have it's pros and cons.
In case of dynamic deployment your model is stranded away from all
other customization related code. So, whenever you deploy all your
customization on particular instance you will not be able to include
them in your amp file.
In case of bootstrap deployment if you have any syntactical error in
model you will get to know during bootstrap with information on
possible cause of issue. So, it's easier to rectify.
Dynamic deployment seems to be better suited for your development environment if you want to quickly implement your model and check changes.
As stated in the Alfresco documentation:
There are restrictions on what changes you can make to a content model XML file and when you can delete a content model XML file. Only incremental additions are allowed; i.e., changes that do not require modifications to existing data in the content repository, or do not modify existing definitions and their properties. You can delete the content model only if it is not used by any data in the content repository.
I do not think that dynamic deployment is a good option during development because you will likely need to modify your content model often with changes that are not incremental (such as removing a property). There are steps that you can follow to remove a property from a model dynamically loaded, but they will be much slower and error prone than a restart.
Dynamic deployment is good only in some particular use cases (for example if you need to add a new content type on the fly).
To test that a content model is well formed, you do not need to deploy it. Instead, use the "TestModel" class as described in
https://forums.alfresco.com/forum/developer-discussions/development-environment/orgalfrescorepodictionarytestmodel-11172011-2133
and in many other forum posts
So my problem is exactly the same as this guy's here: http://www.pubbs.net/201003/flex/61462-flexcoders-flash-builder-super-class-regeneration.html , but unfortunately, he got no answer.
After initially generating service classes connecting with PHP, I modified the PHP, added new call specifically.
While the Data/Services window successfully made notice of the changes, including new function in the list, the service super-class didn't change whatsoever. Which baffles me, since all super-classes in generated service and valueObject packages contain an annotation like this:
This is a generated class and is not intended for modification. To customize behavior
of this service wrapper you may modify the generated sub-class of this class - SomethingService.as.
And also the sub-class contains something about "regeneration of the super-class". So obviously, my goal is to force the mentioned regeneration. Any thoughts?
Just had a similar problem and it was driving me nuts. In my case, I am using an Eclipse plug-in for Team Foundation Server (a source control repository). In TFS, files are kept read-only until you check them out. Usually when something behind the scenes tries to modify a file that I have open, the plug-in will check out the file automatically and let it make the changes. For some reason, it didn't in this case.
So for me, all I had to do was check out the file and it would then be able to regenerate (which translates to making the file writable for the rest of you who might have the same issue).
I find that most code generators work once to generate classes, but do not work well updating them. It's really hard (I've worked on them).
Can you correct your classes by hand?
Is there any way to show local tasks to user if they doesn't have necessary permissions? Right now it seems like Drupal just excludes them from page code. I want to show them, but with different CSS class.
Version of Drupal is 5.20
Even though there are some differences concerning the local task building between Drupal 5 and 6, Mac is right that the logic to ignore entries not accessible by the current user is pretty deeply embedded in the menu.inc functions. If you want to look for yourself, start with theme_menu_local_tasks() and follow the function calls from there.
If I had to implement the feature you're looking for, I'd rather avoid Macs suggestion of messing around with the menu access settings directly. Instead, I'd override theme_menu_local_tasks() with a custom version and duplicate the entry retrieval logic in there. The first run would fetch the primary and secondary links as before, and the second would do the same while impersonating another user (probably user 1 in this case). That way, I'd get two versions of the local task markup which I'd then needed to diff somehow in order to find the ones not allowed for the current user, thus needing the extra CSS class.
Note that this would still be somewhat ugly to do, as menu_primary_local_tasks() and menu_secondary_local_tasks() return already themed lists, so the comparison would need to work on the markup, probably parsing out the li tags somehow. So it might be worth spending some time trying to do the same thing (fetching the local tasks as two different users), but using lower level functions to get the entries before theming.
Note: Should you end up using the user impersonation logic, make sure to use the safe, second version that disables session saving during impersonation.
I know the D6 version of hook_menu much better than D5's. AFAIK - however - you can't override that behaviour as it is hardcoded in menu.inc.
If I am right with what above, a workaround (rather inelegant, I must admit) could be:
Remove the access control from the menu item, so that all menu items are visible to all user.
Put access control in the callback directly (you will make the tab non-clickable in a moment, but if the user insert the URL directly, this will prevent access to pages they must not see).
In the page displaying the tabs, load a different js file according to what roles the user has. The js file for users with limited access will select tabs by mean of their text content (at least in D6 tabs do not get any "individual" class: they only get a common "tab" one), it will remove the link to the tabs the user has no permission to visit and it will add a custom class to those tabs that should be displayed differently.
Add CSS theming for your custom class.
As stated before, I do not know D5 much, so it might also turn out that you can actually achieve what you want in a much cleaner way!