What exactly is the role of the "DWORD64 Rip" variable in this CONTEXT structure that holds processor-specific register data?
I looked at MSDN but they didn't explain it there.
CONTEXT structer in MSDN: https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-context#see-also
Related
I'm looking to share an EF Context between "data manager" objects to ensure change tracking occurs under one context as opposed to handling multiple contexts...so I'm looking into named context... but in review of this documentation, I felt it wasn't clear, and I want to ensure my assumption is correct, and if so, update the documentation: here PRISM documents the resolution of named instances via a constructor:
My assumption is that the named typed "carservice" is matched to the named parameter in the constructor to select which concrete class should be reference to that parameter based on the IVehicleService.
Is my assumption correct - either way I'll create a pull request to clarify the documentation..Either way, answering the question here will add reference to clarification/handling of named instances in PRISM.
It seems this is NOT correct assumption, and it's not possible in Unity - I refactored to avoid.
One solution that I didn't try was to simply another interface (came to mind much later), was inheriting from an existing interface, and registers the "new" interface to use a specific constructor. As I'm new to Unity, I thought I would mention. I'm answering my own question, as I can't don't think I can give credit to a comment, and I HATE leaving questions unanswered on this site!
If a document of ClassA is changed to ClassB, security group of the document doesn't change i.e. it still has ClassA security group.
I'm trying to understand what could be the reason/benefit/advantage behind this?
I expected the security groups changed to Class but not.
In fact, the Documentation says exactly what you summarized in your question:
You can assign a different class to existing document objects. For
example, you might add a document and assign it a document class of
Manuals because you intend it to be a chapter in an installation
manual. Later, you find the document is better placed in your training
materials and change the document class to Courseware. Later still,
you decide to remove it from the manual and make it a Technical
Notice, which has its own document class of Tech Notes®.
Assigning a different class does not:
Change the security permissions that the original document class directly applied to that document object. You can change the security
by editing the security lists of the document object.
Cause the content of existing document objects to be moved. The default storage area and storage policy of the new document class
apply only to new instances of the class.
You can also browse the existing versions of a document to examine the
history of the class assignments for the document. If your saved
searches use the former document class as a search parameter, you
might no longer find the document.
I think that the main reason has to be found in FileNet approach, that - being it an ECM and not a DBMS - sets a distinction between content and metadata. This brings some observations to my mind:
The ACL for a particular Document Class are defined in their Default Instance Security. As the name implies, these are the security rules set by default when an instance of that class is created. This does not mean that a strict bound between a Document Class and their ACL exists, just that a default setting exists.
Consider the example in the Documentation: a document has been reclassified from Manual to Courseware. This could mean that some operations have been done on that document, before the class' change. If those operations were done by users that have visibility on Manuals, but not on Courseware, it's not right to brutally hide that document to those users.
Generally speaking, separating the CHANGE_CLASS permission from others (as WRITE, DELETE, etc...) adds a bit of freedom to software designers and administrators that use FileNet. Considering the example above again, hiding the document (or changing the permissions), could be necessary in case of a transition like "Public Administration -> Top Secret", but it could not be the case of "Manuals > Courseware".
There are two ways to obtain a session attribute in Thymeleaf:
${#session.getAttribute('attr')}
${session.attr}
What is the difference between both session "objects"? Is there a situation in which one would work and not the other?
#session usage only works in Web Context ie. it is a helper to directly access to the javax.servlet.http.HttpSession object associated with the current request. This is clearly stated in documentation. So you are directly accessing the Context object here not the variable that is defined by the thymeleaf.
$session is a shortcut for accessing session attributes. This is not a context object, but it is a map added to the context as a variable, which is added by thymeleaf explicitly. You can find the relevant information here.
I'm working on my pet project where I have the following scenario:
user can create article and becomes its owner
only article owner can edit given article
I wonder how to model it correctly. I don't want to have dumb objects like User and Article that only have properties, but would like them to have some behavior. This is how I'd approach it initially:
article = articles_repository.find(id)
if(article.changeable_by(user))
article.change(title, content)
articles_repository.save(article)
else
raise NoEditRights
end
My only concern here is that I need to check if user can modify before I do modifications. I
Another approach was to pass current user to change method and let article check it and raise error if user is not allowed to change it.
I was also thinking about something like this:
article = articles_repository.find(id)
article.as_user(user) do
article.change(title, content)
articles_repository.save(article)
end
but I don't know if it is any better.
How would you approach such case? How to internally prevent article from being changed by other users I know it is quite simple, but I'd like to grasp how to model such cases before I jump into something more difficult.
EDIT: some more info added
So this is content publishing application, users can write and publish articles, others can read them and comment on them.
This is really simple app (just a toy project) and I can see the following bounded contexts here:
publishing article
editing article
some others that are not important I guess (like comment on article)
I'm not sure if I should introduce different models for each context?
These are not bounded context, but some use cases.
From what you say I guess there will be 2 bounded contexts: publishing and access management. Access management - unless you're willing to introduce some unordinary mechanisms - is a generic concern that probably don't require your focus and DDD - just add some good library that solves this problem already. And maybe wrap it with some application service.
So in some app service there would be a method doing something like (pseudocode, sorry, I don't know Ruby):
var user = auth::authenticationService.getUser(...)
if user.hasAccessTo(articleId) then
var article = pub::articleRepo.get(articleId)
article.doSomething()
end
Note that authentication service and user belongs to one context (auth) and article and article repo to another (pub). There is only a small connection between them. User don't know anything about articles in pub context (it's just a value object storing the id) and article doesn't know anything about access management (but probably has a value object of user that contains his name).
Another way would introduce some tiny objects in pub context like Author, Editor, Commenter representing the roles over the article.
var role = pub::roleService.getAuthorFor(articleId, userId)
if role != null then
role.doSomethingWithArticle()
end
where roleService acts as an anticorruption layer between auth and pub (so it calls a authenticationService, gets user object full of auth-specific stuff and based on it, construct a lightweight role object that contains only pub-specific behavior.
The second example sounds heavier but it's more prone to changes in one of the contexts.
Can someone explain to me when methods are called in WD4A applications? Particularly methods that are defined in the application controller (and not the view (controllers)).
I'm looking at some sample codes and there's this supply_unit method in the componentcontroller which basically reads a few values from a table and puts these in the controller context so they are available in view_2, based on a context node that was assigned a value by the user on view_1.
But I don't see at which point this method actually get's called (the application actually has more than only these two views) and how the application knows that it needs to be called so everything can be shown in view_2
SAP's standard documentation for WebDynpro is pretty good, and goes through all of this. This page (and the pages below it) describe programming controller methods in general. I would suggest taking a couple days and working through all of the WebDynpro for ABAP documentation, coding examples as you go. You'll have a much more complete understanding that way.
Methods should be implemented in the component controller (as opposed to the view controller) when the logic of that method is used (or may be used) across multiple views. For example, if you have a context node thats displayed in multiple nodes (like a list of units of measure), it makes sense to program it's supply method once in the controller, instead of in each view.
Your question seemed to be more about supply functions (SUPPLY_UNIT sounds like the name of a supply function). These are methods that are called automatically by the system the first time a context node is read. They are used to initialize contents of the node. More info can be found here.